Python-сообщество

PooH
Очень сильное утверждение. Обосновать сможете?

О костыле или о причинах его использовать?

Если первое, то o7412369815963 уже написал - в “объектном” мире живем.
Указанные им недостатки РБД характерны именно для задачи хранения и обработки объектов. И только для них.

Если второе, то вкратце: существующие на тот момент технологии (программные и аппаратные) не позволяли добиться приемлемой скорости работы и стоимости.
А потом возникла мода на РБД, которую поддержали банки и биржы.
Кол-во специалистов, занимающихся РБД (созданием и использованием) на порядки превысило специалистов по ОБД.
Были созданы удобные инструменты для работы с РБД.
И т.д. по спирали.

o7412369815963
> Не холивара ради, но это не для всех реляционных баз верное утверждение.
Возможно, пример приведете?

Не знаю, как с другими реляционными, но например: http://pgxn.org/dist/pg-json/
Разумеется, не верх возможностей, но не уверен, что монго в этом плане может что-то сильно большее (было бы интересно сравнить).
Это не считая вообще богатый арсенал Postgres на типы данных и инструментарий работы с ними.

o7412369815963
Если храним имя и фотку в сообщении: 1 (обновлений в месяц) * (сообщений у пользователя) = 1 update на 100 сообщений.

Это красиво выглядит в начале, когда у пользователя всего 100 сообщений. Даже на данном форуме, где общение протекает отнюдь не столь интенсивно, а сами сообщения стремя к объёму, а не количеству, хватает пользователей у кого за тысячу сообщений. В социальной сети, где люди просто общаются на отвлечённые темы, немного иная реальность, общение больше напоминает чат и сообщения в течении года могут переваливать за отметку в десять тысяч. При этом сами комментарии могут быть показаны далеко не так часто как в примере.

В итоге мы будем иметь количество обновлений, уже в близких порядках к количеству чтений, а в перспективе и переваливающее эту границу.

При этом модель хранения “продублируем N раз одну и ту же информацию” исключает возможность кеширования данных как таковую (и Вы почему-то эту возможность вообще не рассматриваете в своей модели, всегда сводя операции чтения к обращениям к диску). Например, на странице обсуждения, где один человек оставил два десятка комментариев его профиль по ссылке будет прочитан только один раз на двадцать сообщений, не считая того, что он вообще в данный момент может храниться в памяти как часто востребованный и не быть прочитанным с диска вообще ни разу. Также не считая того, что при меньшем объёме информации на одну дискуссию будет прочитано меньше (в лучшем случае последовательных) дисковых страниц.

В случае использования недисковых накопителей, вопрос времени доступа к данным резко теряет в важности, вопрос же объёма, прогоняемых через систему накопления, данных поднимается на новый уровень. Аналогично при сохранении/кешировании данных в памяти (что можно считать частным случаем).

doza_and
1 при разработке с нереляционной DB меньше трудоемкость поскольку проще ORM.
2 В обычной DB все очень плоско и доступно - те все таблицы глобальны нет скрытых полей(колонок) нет наследования и т.п. Для проектов с большим количеством таблиц/классов это затрудняет разработку.

Вывод, к которому я пришёл: и первый, и второй пункты являются как достоинством, так и недостатком указанных моделей в соответствующих ситуациях.

С одной стороны схема - требует ресурсов на своё поддержание со стороны разработчиков, модификация схемы может оказаться ресурсоёмкой и блокирующей операцией на критичных к этому системах. Соответственно бессхемная реализация на этапе создания прототипа и для небольшого коллектива разработчиков даёт очевидный плюс в виде экономии времени.

С другой стороны схема - гарантирует наличие определённых данных и их формата, улучшая контроль над сложной системой, в которой задействован большой коллектив разработчиков, поскольку схему в виде условных договорённостей, что где должно лежать - всё равно придётся документировать, но встроенная схема даст и реальный контроль над “живыми” данными и всей инфраструктурой с этими данными работающей. Что в том случае - тоже экономия времени, только уже за счёт ловли багов на участках кода, где что-то “подразумевается”, но без схемы - не очевидно.

Соответственно можно совместить достоинства этих парадигм в некой третьей гибридной реализации. Или собрать грабли с обоих ))

Lexander
Как же нет? В 1-м посте автор темы указал необходимость объединить данные 2-х коллекций. Коллекция=таблица.

Видимо мы понимаем несколько разные операции под словом “объединение”. Впрочем, английские понятия join и union накладываются в русском.
Хорошо, здесь у нас операция union. В чём её “реляционность”? Тем более, что практически все данные на уровне хранилища в данной теме предлагается превентивно соединить через union.
Но если данные берутся из двух коллекций (в SQL - это тоже два вложенных запроса), а затем фильтруются по некоему общему для выборки признаку (по сути промеждуточный результат находится в неком временном хранилище) - это уже противоречит духу mongo? (духу, не текущей реализации, с которой уже разобрались). Признаюсь честно, меня до сих смущают сплошные примеры в документации, где в качестве образца каждая сущность имеет свою коллекцию. Хотя не могу не признать, что в текущей реализации - если не свалить всё в одну кучу, работать с данными выше уровня хранилища “ключ/значение” - практически невозможно. При этом в каждом документе нужно хранить некий признак к какому классу он относится, использовать этот признак в запросах, вместо того, чтобы использовать для классификации встроенную возможность дерева коллекций. Когнитивный диссонанс ))

Lexander
Большинство бизнес-задач связаны с обработкой документов, поэтому нужно использовать ОБД.

Понятие “документ” не совсем синонимично понятию объект, поэтому причинно-следственная связь не очевидна. Более того, в большинстве бизнес процессов обрабатываются именно регламентированные списки-таблицы. А вот описание сущностей, которые отражаются в бизнес-процессах, для человека - в таблицы вписывать уже не всегда удобно, да. Но не потому, что таблицы чем-то для этого сильно хуже, а потому что их используют не на том уровне абстракции, решая задачу “в лоб”. Вот интересный пример разнесения уровней абстракции: http://citforum.ru/database/articles/tempo_eis/

Lexander
Для РБД такие изменения очень болезненны, т.к. нужно вносить изменения сразу в несколько мест: структуру БД, серверный и клиентский код.

Изменение схемы работы с базой и на бессхемной БД потребует внесения изменений в серверный и клиентский код. Отличие только в том, что управление структурой данных осуществляет не сама база, а сервер приложений. А какие изменения в РБД делают изменение схемы хранения данных более сложной по сравнению с ОБД? Добавилась в описании сущности пара полей - и в РБД, и в ОБД примерно одинаковое количество изменений, только РБД хранит в себе информацию о возможности этих полей, а в бессхемной БД - пока с ними не столкнёшься или не прочитаешь из спецификации проекта, не узнаешь, что могут быть - описание будет и тут и там, но во втором случае - меньше контроля. (Если мы делаем сравнение со случаем, когда сервер и клиент ОБД автоматом подхватывают появление новых элементов в записях, то сравнивать стоит с аналогичным случаем для РБД).

Lexander
Для РБД создание одного запроса на выборку данных - идеал разработчика почти для всех СУБД.

Возможно я чего-то не знаю, но из чего следует такое утверждение?

На прикладном уровне подобный подход как минимум лишает возможности частичного кеширования данных вне базы неоправданно повышая нагрузку на узкую часть системы - БД. Извлечение данных одним запросом, имхо, хорошо в аналитике со сложными условиями выборки, касающимися большого набора исходных данных и имеющего на выходе малый объём да ещё и уникальных данных (а не просто значений из приджойненных табличек), где дешевле перевычислить данные на сервере базы, чем перегонять всю базу между сервером БД и сервером приложений. Но и тут как бы никто не отменял сохранение промежуточных результатов вычислений.

Длина же транзакции - это отдельная песня, короткие транзакции отнюдь не догма, хотя и рациональное правило. Здесь всё упирается в блокировки общих ресурсов, избыточную оптимистичность запросов и т.п. оптимизации, но в некоторых случаях они допустимы, а иногда, как в случае со сложной аналитикой - вообще неизбежны.

Lexander
system-level view for embedded objects

Мммм, о чём в данном случае идёт речь? Аналог VIEW SQL?

o7412369815963
Табличный способ хранения имеет кучу ограничений: фиксированный размер полей, хранить можно только определенные поля, нельзя выкинуть не нужные поля и т.д…. - это все ограничения, а ограничения - есть не удобство.

* фиксированный размер полей - зависит от реализации и выбора типа данных, размер полей может быть и нефиксированным (условно неограниченным)
* некоторые типы данных предоставляют свободу в этом вопросе, вплоть до хранения сериализованных данных в text/blob
* нельзя выкинуть не нужные поля - не совсем понятно, почему их нельзя выкинуть? NULLable же?

o7412369815963
в “объектном” мире живем

Тут некоторая неточность. Мы живём в стеке клеточных автоматов и сами же участвуем в одном из уровней этого стека. “Объектность” - лишь один из способов думать, не самый худший, но и не идеальный (если вообще существует идеальный), хотя и привычным в “обыденном” мире. Но если доводилось строить большие иерархии объектов в ООП, то думаю не надо объяснять, что не всё так просто и однозначно.

Отредактировано (Дек. 10, 2011 01:11:10)

> но не уверен, что монго в этом плане может что-то сильно большее (было бы интересно сравнить).
эквивалентно “я не знаю”

> Возможно я чего-то не знаю, но из чего следует такое утверждение?
- вопрос против явного

> * нельзя выкинуть не нужные поля - не совсем понятно, почему их нельзя выкинуть? NULLable же?
техника “прикинуться дурачком”, т.к. вы сами понимаете что удаление != присвоить “ноль”

> Это красиво выглядит в начале, когда …
попытка вытянуть факт в другую плоскость (подмена фактов, цифр о которых не разговаривали), “если бы, то кабы…”

blessmaster

o7412369815963
Табличный способ хранения имеет кучу ограничений: фиксированный размер полей, хранить можно только определенные поля, нельзя выкинуть не нужные поля и т.д…. - это все ограничения, а ограничения - есть не удобство.

* фиксированный размер полей - зависит от реализации и выбора типа данных, размер полей может быть и нефиксированным (условно неограниченным)
* некоторые типы данных предоставляют свободу в этом вопросе, вплоть до хранения сериализованных данных в text/blob
* нельзя выкинуть не нужные поля - не совсем понятно, почему их нельзя выкинуть? NULLable же?

Сначала попробуйте сделать опровержение “философскому”: ограничение - есть не удобство.

Lexander

blessmaster
Какбэ необходимость требует по зависимости возможность.

Я не понял смысла этой фразы. Вы подтверждаете мое высказывание, но почему то делаете это в опровергающем стиле.

Попытка переспорить.

В “поэме” много заблуждений, домыслов и неуверенности, попытка “обспорить” каждое предложение.
Диагноз - вы просто спорщик.

Поэтому, что-б сэкономить кучу времени, переводим тему в другую плоскость, т.к. это тема про MongoDB, вы задаете короткий вопрос по монге - мы отвечаем.

Отредактировано (Дек. 10, 2011 10:00:33)

В дискуссии был приведен пример с форумом.
Из всего выше сказанного для меня пока осталось не ясно как в mongo осуществить оптимизацию загрузки последних 20 сообщений пользователя (т.е. учесть что они почти всегда запрашиваются вместе). Или аналогично - как задать в mongo плотность вероятности запросов элементов коллекции. Как РСУБД это сделать тоже не очень понятно.

Отредактировано (Дек. 10, 2011 11:25:31)

blessmaster
Разумеется, не верх возможностей, но не уверен, что монго в этом плане может что-то сильно большее (было бы интересно сравнить).
Это не считая вообще богатый арсенал Postgres на типы данных и инструментарий работы с ними.

pg-json умеет делать меньше 10 операций.
Причем все операции сводятся к преобразованию в строку.
У Монго есть язык запросов.

blessmaster
Хорошо, здесь у нас операция union. В чём её “реляционность”?

Я действительно имел ввиду join.
Впрочем специфика (ограничения) union как раз и показывает ее реляционную сущность. Например, соблюдение порядка следования, кол-ва и типов полей в запросе.
Собственно, у меня даже мыслей не было, что речь может идти о union, если в постановке задачи фигурировали РАЗНЫЕ ПО СТРУКТУРЕ коллекции (таблицы).

blessmaster
Более того, в большинстве бизнес процессов обрабатываются именно регламентированные списки-таблицы.

Что такое документ в подавляющем большинстве бизнес-процессов?
Это шапка документа и его тело.
На этом этапе уже можно остановиться и не вспоминать о теле документа со сложной структурой (например, 2-3 таблицы).

Тело документа, действительно, зачастую - таблица. И хранить ее естественно в табличном виде.
Тем не менее, мы имеем ОДНУ сущность, которую вынуждены разбить на несколько и поместить в разные таблицы.

blessmaster
Изменение схемы работы с базой и на бессхемной БД потребует внесения изменений в серверный и клиентский код. Отличие только в том, что управление структурой данных осуществляет не сама база, а сервер приложений.

Сервер приложений может отсутствовать. Давайте не будем нагромождать частные случаи.
Впрочем, сервер приложений - это тоже еще одно место, где меняется код. Причем этот частный случай вносит еще больше проблем, т.к. при обновлении нужно будет этот самый сервер приложений остановить. Т.е. ваша система не будет работать Н-ное кол-во времени.

Чем меньше кол-во мест, где нужно вносить изменения, тем проще система.

blessmaster
Добавилась в описании сущности пара полей - и в РБД, и в ОБД примерно одинаковое количество изменений, только РБД хранит в себе информацию о возможности этих полей, а в бессхемной БД - пока с ними не столкнёшься или не прочитаешь из спецификации проекта, не узнаешь, что могут быть - описание будет и тут и там, но во втором случае - меньше контроля.

Уже после первой сотни таблиц (вне зависимости от рода БД) проще смотреть спецификацию, где помимо структуры таблицы (для РБД) описаны все ограничения и преобразования каждого поля. В РБД поле у вас описано в одном месте, ограничения на него - в другом, триггеры на разные события и возможные преобразования значений - в третьем.

Раньше структуру РБД (и остальные плюшки) хоть можно было использовать для контроля правильности данных.
Нынче проверка данных проводится на на всех участках цепи: от клиента до СУБД.
Требования в ПО другие.

blessmaster
Возможно я чего-то не знаю, но из чего следует такое утверждение?

Посмотрите на вопросы, которые поднимаются на sql.ru и посты в блогах гуру.
Спрашивают и пишут люди - разработчики.
Хотя все знают (так говорят доки), что чем сложнее запрос, тем больше ресурсов он кушает.
Например, для MS SQL Server 2005 и выше рекомендуют TEMP базу размещать на отдельных носителях, подключенных к отдельному каналу дискового контроллера.
Иначе производительность падает.

blessmaster
Длина же транзакции - это отдельная песня, короткие транзакции отнюдь не догма, хотя и рациональное правило.

Зачем же вырывать длину транзакции из описываемого контекста и делать ее отдельной песней?
Нет, она указана вторым пунктом и связана единой мыслью.
И да, это не догма, это best practice.
Ведь блокировок никто не любит.

blessmaster
Мммм, о чём в данном случае идёт речь? Аналог VIEW SQL?

Да. В том числе, materialized.

blessmaster
фиксированный размер полей - зависит от реализации и выбора типа данных, размер полей может быть и нефиксированным (условно неограниченным)

И тем самым потребует больших ресурсов. Дорого.

blessmaster
некоторые типы данных предоставляют свободу в этом вопросе, вплоть до хранения сериализованных данных в text/blob

Зато напрочь лишают возможности использовать встроенные возможности СУБД.
Начиная с индексов, и заканчивая функциями.
А то, что работает, делает это существенно медленнее операций над простыми типами.

blessmaster
нельзя выкинуть не нужные поля - не совсем понятно, почему их нельзя выкинуть? NULLable же?

update table set field=NULL
и
alter table drop field

все же разные операции ;)

doza_and
В дискуссии был приведен пример с форумом.
Из всего выше сказанного для меня пока осталось не ясно как в mongo осуществить оптимизацию загрузки последних 20 сообщений пользователя (т.е. учесть что они почти всегда запрашиваются вместе)

Метод зависит от вида нагрузки, например если просмотров много, а изменений мало, может подойти такой вариант.
Например можно хранить массив этих 20 сообщений в объекте пользователя, и обновлять этот массив при добавлении сообщения либо при первом обращении. В итоге сделав 1 запрос мы получим пользователя и в добавок будем иметь его 20 последних сообщений.

o7412369815963
эквивалентно “я не знаю”

Возможно я где-то случайно обронил “пишу книгу МонгоДБ для профессионалов”?

o7412369815963
> Возможно я чего-то не знаю, но из чего следует такое утверждение?
- вопрос против явного

Мне конечно приятно сознавать, что кому-то что-то “явно”, но странно, что своим пониманием явности, он не желает делиться, но для чего-то участвует в дискуссии отвечая общими фразами а-ля “ну это же очевидно”.

o7412369815963
попытка вытянуть факт в другую плоскость (подмена фактов, цифр о которых не разговаривали), “если бы, то кабы…”

Мы разговаривали в первую очередь не о цифрах, а об архитектуре. В одном наборе тестовых данных Вы находите превосходство подхода, на другом наборе вдруг возражаете: “мы так не договаривались”.
Мы рассматривали случай базы имеющей свойство расти и интересно поведение архитектуры не только через пять минут, но и через год, когда что-то поменять будет сложно, поэтому такие вещи нужно продумывать заранее. Не понимаю откуда в техническом обсуждении берётся эмоциональность? Ок, появились новые цифры, давайте рассматривать это как новый вопрос, раз старый исчерпан.

o7412369815963
Сначала попробуйте сделать опровержение “философскому”: ограничение - есть не удобство.

Вообще-то с этого “философского” начался весь топик.

o7412369815963
вы задаете короткий вопрос по монге - мы отвечаем

Полагаю, если я вижу в сообщениях других участников публичной дискуссии неточности, недосказанности и прочие искажения, я всё же имею право отметить это, не так ли?

Lexander
pg-json умеет делать меньше 10 операций.
Причем все операции сводятся к преобразованию в строку.
У Монго есть язык запросов.

Остальные операции умеет делать сам постгрес (на всякий случай, о каких операциях мы говорим?)
По поводу ограниченности конкретно этого расширения - как выясняется автор вообще создал его ради развлечения, так что, может быть это и не совсем удачный пример. В постгресе есть и более мощные расширения реализующие дерево через XML, но речь шла про json, поэтому выбор примера пал на это расширение.
Тем не менее возможностей поиска это не отменяет, как минимум сравнение в нём производится не по строке. Сами же данные хранятся в двоичном виде. В postgres также есть механизм вычисляемых индексов, что близко по смыслу к map.
Разработчик приводит такой оразец запроса:
select
id,
(data -> ‘first_name’)::text as “First Name”,
(data -> ‘last_name’)::text as “Last Name”,
(data -> ‘email.work’)::text as “Work Email”,
(data -> ‘email.personal’)::text as “Personal Email”
from users;
Полагаю, когда реализована эта функциональность, ничто не мешает оператору -> появиться в where секции (преобразование типа здесь использовано, поскольку фрагмент джейсона также является джейсоном в текущей реализации расширения).

Lexander
Впрочем специфика (ограничения) union как раз и показывает ее реляционную сущность. Например, соблюдение порядка следования, кол-ва и типов полей в запросе.
Собственно, у меня даже мыслей не было, что речь может идти о union, если в постановке задачи фигурировали РАЗНЫЕ ПО СТРУКТУРЕ коллекции (таблицы).

В данном случае о структуре говорить вообще сложно, поскольку между соседними документами коллекции может не оказаться вообще никакого сходства. Если обобщать, то мы можем сравнить коллекцию монго с одноколоночной таблицей реляционной базы, колонка которой имеет тип json (это условное сравнение, поскольку реляционный подход такого не допускает и имеющиеся решения - гибрид с нереляционными). В таком описании слияние двух коллекций есть ничто иное как union.
Точно так же и выборка ведётся не по структуре, а по соответствию паттерну структуры. Именно поэтому мне здесь сложно увидеть классическую реляционность, но, возможно, я не учитываю не очевидных мне нюансов?

Lexander
Тело документа, действительно, зачастую - таблица. И хранить ее естественно в табличном виде.
Тем не менее, мы имеем ОДНУ сущность, которую вынуждены разбить на несколько и поместить в разные таблицы.

Это лишь часть картины.
С одной стороны, шапка документа - тоже таблица для набора документов. Роль таблиц здесь - в задании правил обработки этих документов. Правила требуют определённых данных на входе и мы никуда от этого не денемся. Сохраняя документы в бессхемной БД, мы всё равно будем вынуждены следовать регламенту, хотя возможности по сохранению информации о документе оказываются шире. Несомненным достоинством бессхемной базы является именно более гибкая возможность расширения регламента. Но данные по прежнему должны соответствовать ожиданиям приложения.
Теперь другая сторона - данные документа являются составляющей не одной сущности, а нескольких, документ - лишь одна из них. Работая с документами нам кажется естественным сгруппировать эти данные в одном месте. Работая с движением товаров и финансов, это уже не кажется столь естественным. Дерево - это вообще очень не универсальная структура. Значительно универсальнее фасетная классификация.
Например в документе мы хотим видеть контрагентов и список товаров. У контрагента мы хотим видеть список документов и список товаров. У каждого из складов мы хотим видеть список документов и список товаров. Что чему здесь должно быть корнем иерархии? Строгая иерархия здесь неприменима. Поэтому мы и приходим к понятию множества записей, в котором документ - это один способ объединить элементы множества в сущность, движение конкретного склада - другой способ, движение контрагента - третий. То же самое не с товарами, а работами и услугами - здесь ещё сложнее картина - добавляется объединение по цехам, бригадам и отдельным исполнителям работ. Отдельная разговор: время как сущность, которой соответствуют наборы фактов и связанных с ними сущностей.
Фасетная классификация - это именно та задача, для решения которой идеально подходят таблицы.
Про аналоги же этой классификации в монго (как решаются подобные задачи за неимением таблиц) - я и спрашивал несколькими постами выше в примере про социальную сеть. Вот у нас пользователь “тысячник”, у которого число друзей перевалило уже не за одну тысячу (или сообщество соответствующего размера - я сам в фейсбуке состоял в одном сообществе, насчитывающем более миллиона человек). Он решает посмотреть, что там у его друзей творится или что нового члены сообщества пишут. Что мы делаем? По описанной выше схеме берём список его друзей, перегоняем его из базы в память приложения, напрягая сеть и память приложения. Делаем запрос, в котором список этих друзей перегоняем обратно в базу и получаем в ответ пару десятков сообщений. Но гонять эти данные туда-сюда - это явный оверхед, почему просто не сказать базе - “возьми этот набор оттуда-то”, если этот набор всё равно придётся брать? (2 o7412369815963) Поэтому вопрос “как сделать эффективно?” всё ещё актуален.
Монго - изначально позиционируется как СУБД для “больших данных”, поэтому приём пустой перегонки данных мне тем более не кажется эффективным, хотя и есть частные случаи, где таких оверхедов не возникнет, но они очень узкие и смена потребностей клиента потенциально готова убить идиллию на корню.
Сорри, половина этого ответа получилась уже не совсем в ответ на Ваше сообщение, а скорее в рамках дискуссии в целом.

Lexander
Сервер приложений может отсутствовать. Давайте не будем нагромождать частные случаи.
Впрочем, сервер приложений - это тоже еще одно место, где меняется код. Причем этот частный случай вносит еще больше проблем, т.к. при обновлении нужно будет этот самый сервер приложений остановить. Т.е. ваша система не будет работать Н-ное кол-во времени.

Да, сервер приложений может отсутствовать, его функционал может быть вынесен прямо в базу или наоборот в клиент (хотя, имхо, трёхзвенка - куда более общий случай). Модификация этого фрагмента системы в любом случае потребуется, хотя скорее всего она будет и меньше. Для приложений не требующих строгого контроля над структурой данных - этот контроль действительно будет оверхедом, особенно если модификация структуры будет блокирующей. Точно так же, там где он нужен, но отсутствует - ошибки клиента или сервера приложений - породят оверхед по их выявлению и устранению. Что ресурсно дороже - это фактор выбора архитектуры.

Lexander
Уже после первой сотни таблиц (вне зависимости от рода БД) проще смотреть спецификацию, где помимо структуры таблицы (для РБД) описаны все ограничения и преобразования каждого поля. В РБД поле у вас описано в одном месте, ограничения на него - в другом, триггеры на разные события и возможные преобразования значений - в третьем.
Раньше структуру РБД (и остальные плюшки) хоть можно было использовать для контроля правильности данных.
Нынче проверка данных проводится на на всех участках цепи: от клиента до СУБД.
Требования в ПО другие.

Для больших систем человекочитаемая документация незаменима, но всё же ожидания базы при наличии схемы - описаны языком этой базы и их можно прочитать до документации. В документации - уже смысл этих ограничений.
Контроль же на других уровнях диктуется не этим.
Сервер приложений - разгружает уровень базы, которая является бутылочным горлышком (а благодаря меньшей связности своих проверок дешевле масштабируем) и контролирует клиенты, которых может быть много различных реализаций и версий.
Клиент своими проверками - разгружает уровень сервера приложений и сеть, но клиенту доверять нельзя принципиально, поэтому все его проверки носят лишь рекомендательный характер и удалённая сторона при желании может их обойти.

Lexander
И тем самым потребует больших ресурсов. Дорого.

Не совсем понятно. Монго - содержит нефиксированную структуру данных условно неограниченную (технические ограничения есть, но мы до них же не доходим в обоих случаях?). Это разве дорого?

Lexander
Зато напрочь лишают возможности использовать встроенные возможности СУБД.
Начиная с индексов, и заканчивая функциями.

Если брать сериализацию на уровне клиента и двоичные данные, то да, есть только возможность сохранения произвольной структуры (с некоторыми оговорками про поиск подстроки или соответствия регулярке), если это сохранение, решаемое соответствующими типами данных, то нет, даже наоборот, появляются дополнительные возможности индексации множеств и поиска по такому индексу в виде соответствующих операций с множествами.

Lexander
update table set field=NULL
и
alter table drop field
все же разные операции wink

Разумеется, поскольку одна операция - исключение из обязательности участия в запросах соответствующего столбца (причём я имел в виду ALTER COLUMN … DROP NOT NULL с фоновой очисткой “лишних” значений), после чего клиент может работать с этой базой с незначительным оверхедом по занимаемому дисковому пространству, что на фоне других оверхедов достаточно незначительно, если только мы не обнуляем две трети столбцов. Второй же вариант - это обязательный оверхед на простое при переструктурировании хранилища. По этой и другим причинам я склонен к предпочтению первого варианта (а ведь никто не догадался, почему-то выбросить значение всем показалось сложной задачей) - когда-нибудь может понадобиться и добавить столбец, а без соответствующего резерва оверхед второго сценария неизбежен и это именно то место, где бессхемные и гибридные решения бесспорно выигрывают.

У меня в одном из проектов все данные (разные документы, пользователи, настройки пользователей) были в одной колекции - очень удобно. Отдельные колекции использовались для кеширования, хранения истории, и пр. вспомогательных вещей.

Отредактировано (Фев. 8, 2012 09:29:45)

Пасибо общее направление примерно понятно). Придется действительно все собирать в одну коллекцию по возможности.