Форум сайта python.su
PooHО костыле или о причинах его использовать?
Очень сильное утверждение. Обосновать сможете?
Офлайн
o7412369815963Не знаю, как с другими реляционными, но например: http://pgxn.org/dist/pg-json/
> Не холивара ради, но это не для всех реляционных баз верное утверждение.
Возможно, пример приведете?
o7412369815963Это красиво выглядит в начале, когда у пользователя всего 100 сообщений. Даже на данном форуме, где общение протекает отнюдь не столь интенсивно, а сами сообщения стремя к объёму, а не количеству, хватает пользователей у кого за тысячу сообщений. В социальной сети, где люди просто общаются на отвлечённые темы, немного иная реальность, общение больше напоминает чат и сообщения в течении года могут переваливать за отметку в десять тысяч. При этом сами комментарии могут быть показаны далеко не так часто как в примере.
Если храним имя и фотку в сообщении: 1 (обновлений в месяц) * (сообщений у пользователя) = 1 update на 100 сообщений.
doza_andВывод, к которому я пришёл: и первый, и второй пункты являются как достоинством, так и недостатком указанных моделей в соответствующих ситуациях.
1 при разработке с нереляционной DB меньше трудоемкость поскольку проще ORM.
2 В обычной DB все очень плоско и доступно - те все таблицы глобальны нет скрытых полей(колонок) нет наследования и т.п. Для проектов с большим количеством таблиц/классов это затрудняет разработку.
LexanderВидимо мы понимаем несколько разные операции под словом “объединение”. Впрочем, английские понятия join и union накладываются в русском.
Как же нет? В 1-м посте автор темы указал необходимость объединить данные 2-х коллекций. Коллекция=таблица.
LexanderПонятие “документ” не совсем синонимично понятию объект, поэтому причинно-следственная связь не очевидна. Более того, в большинстве бизнес процессов обрабатываются именно регламентированные списки-таблицы. А вот описание сущностей, которые отражаются в бизнес-процессах, для человека - в таблицы вписывать уже не всегда удобно, да. Но не потому, что таблицы чем-то для этого сильно хуже, а потому что их используют не на том уровне абстракции, решая задачу “в лоб”. Вот интересный пример разнесения уровней абстракции: http://citforum.ru/database/articles/tempo_eis/
Большинство бизнес-задач связаны с обработкой документов, поэтому нужно использовать ОБД.
LexanderИзменение схемы работы с базой и на бессхемной БД потребует внесения изменений в серверный и клиентский код. Отличие только в том, что управление структурой данных осуществляет не сама база, а сервер приложений. А какие изменения в РБД делают изменение схемы хранения данных более сложной по сравнению с ОБД? Добавилась в описании сущности пара полей - и в РБД, и в ОБД примерно одинаковое количество изменений, только РБД хранит в себе информацию о возможности этих полей, а в бессхемной БД - пока с ними не столкнёшься или не прочитаешь из спецификации проекта, не узнаешь, что могут быть - описание будет и тут и там, но во втором случае - меньше контроля. (Если мы делаем сравнение со случаем, когда сервер и клиент ОБД автоматом подхватывают появление новых элементов в записях, то сравнивать стоит с аналогичным случаем для РБД).
Для РБД такие изменения очень болезненны, т.к. нужно вносить изменения сразу в несколько мест: структуру БД, серверный и клиентский код.
LexanderВозможно я чего-то не знаю, но из чего следует такое утверждение?
Для РБД создание одного запроса на выборку данных - идеал разработчика почти для всех СУБД.
LexanderМммм, о чём в данном случае идёт речь? Аналог VIEW SQL?
system-level view for embedded objects
o7412369815963* фиксированный размер полей - зависит от реализации и выбора типа данных, размер полей может быть и нефиксированным (условно неограниченным)
Табличный способ хранения имеет кучу ограничений: фиксированный размер полей, хранить можно только определенные поля, нельзя выкинуть не нужные поля и т.д…. - это все ограничения, а ограничения - есть не удобство.
o7412369815963Тут некоторая неточность. Мы живём в стеке клеточных автоматов и сами же участвуем в одном из уровней этого стека. “Объектность” - лишь один из способов думать, не самый худший, но и не идеальный (если вообще существует идеальный), хотя и привычным в “обыденном” мире. Но если доводилось строить большие иерархии объектов в ООП, то думаю не надо объяснять, что не всё так просто и однозначно.
в “объектном” мире живем
Отредактировано (Дек. 10, 2011 01:11:10)
Офлайн
> но не уверен, что монго в этом плане может что-то сильно большее (было бы интересно сравнить).
эквивалентно “я не знаю”
> Возможно я чего-то не знаю, но из чего следует такое утверждение?
- вопрос против явного
> * нельзя выкинуть не нужные поля - не совсем понятно, почему их нельзя выкинуть? NULLable же?
техника “прикинуться дурачком”, т.к. вы сами понимаете что удаление != присвоить “ноль”
> Это красиво выглядит в начале, когда …
попытка вытянуть факт в другую плоскость (подмена фактов, цифр о которых не разговаривали), “если бы, то кабы…”
blessmasterСначала попробуйте сделать опровержение “философскому”: ограничение - есть не удобство.o7412369815963* фиксированный размер полей - зависит от реализации и выбора типа данных, размер полей может быть и нефиксированным (условно неограниченным)
Табличный способ хранения имеет кучу ограничений: фиксированный размер полей, хранить можно только определенные поля, нельзя выкинуть не нужные поля и т.д…. - это все ограничения, а ограничения - есть не удобство.
* некоторые типы данных предоставляют свободу в этом вопросе, вплоть до хранения сериализованных данных в text/blob
* нельзя выкинуть не нужные поля - не совсем понятно, почему их нельзя выкинуть? NULLable же?
LexanderПопытка переспорить.blessmasterЯ не понял смысла этой фразы. Вы подтверждаете мое высказывание, но почему то делаете это в опровергающем стиле.
Какбэ необходимость требует по зависимости возможность.
Отредактировано (Дек. 10, 2011 10:00:33)
Офлайн
В дискуссии был приведен пример с форумом.
Из всего выше сказанного для меня пока осталось не ясно как в mongo осуществить оптимизацию загрузки последних 20 сообщений пользователя (т.е. учесть что они почти всегда запрашиваются вместе). Или аналогично - как задать в mongo плотность вероятности запросов элементов коллекции. Как РСУБД это сделать тоже не очень понятно.
Отредактировано (Дек. 10, 2011 11:25:31)
Офлайн
blessmasterpg-json умеет делать меньше 10 операций.
Разумеется, не верх возможностей, но не уверен, что монго в этом плане может что-то сильно большее (было бы интересно сравнить).
Это не считая вообще богатый арсенал Postgres на типы данных и инструментарий работы с ними.
blessmasterЯ действительно имел ввиду join.
Хорошо, здесь у нас операция union. В чём её “реляционность”?
blessmasterЧто такое документ в подавляющем большинстве бизнес-процессов?
Более того, в большинстве бизнес процессов обрабатываются именно регламентированные списки-таблицы.
blessmasterСервер приложений может отсутствовать. Давайте не будем нагромождать частные случаи.
Изменение схемы работы с базой и на бессхемной БД потребует внесения изменений в серверный и клиентский код. Отличие только в том, что управление структурой данных осуществляет не сама база, а сервер приложений.
blessmasterУже после первой сотни таблиц (вне зависимости от рода БД) проще смотреть спецификацию, где помимо структуры таблицы (для РБД) описаны все ограничения и преобразования каждого поля. В РБД поле у вас описано в одном месте, ограничения на него - в другом, триггеры на разные события и возможные преобразования значений - в третьем.
Добавилась в описании сущности пара полей - и в РБД, и в ОБД примерно одинаковое количество изменений, только РБД хранит в себе информацию о возможности этих полей, а в бессхемной БД - пока с ними не столкнёшься или не прочитаешь из спецификации проекта, не узнаешь, что могут быть - описание будет и тут и там, но во втором случае - меньше контроля.
blessmasterПосмотрите на вопросы, которые поднимаются на sql.ru и посты в блогах гуру.
Возможно я чего-то не знаю, но из чего следует такое утверждение?
blessmasterЗачем же вырывать длину транзакции из описываемого контекста и делать ее отдельной песней?
Длина же транзакции - это отдельная песня, короткие транзакции отнюдь не догма, хотя и рациональное правило.
blessmasterДа. В том числе, materialized.
Мммм, о чём в данном случае идёт речь? Аналог VIEW SQL?
blessmasterИ тем самым потребует больших ресурсов. Дорого.
фиксированный размер полей - зависит от реализации и выбора типа данных, размер полей может быть и нефиксированным (условно неограниченным)
blessmasterЗато напрочь лишают возможности использовать встроенные возможности СУБД.
некоторые типы данных предоставляют свободу в этом вопросе, вплоть до хранения сериализованных данных в text/blob
blessmasterupdate table set field=NULL
нельзя выкинуть не нужные поля - не совсем понятно, почему их нельзя выкинуть? NULLable же?
Офлайн
doza_andМетод зависит от вида нагрузки, например если просмотров много, а изменений мало, может подойти такой вариант.
В дискуссии был приведен пример с форумом.
Из всего выше сказанного для меня пока осталось не ясно как в mongo осуществить оптимизацию загрузки последних 20 сообщений пользователя (т.е. учесть что они почти всегда запрашиваются вместе)
Офлайн
o7412369815963Возможно я где-то случайно обронил “пишу книгу МонгоДБ для профессионалов”?
эквивалентно “я не знаю”
o7412369815963Мне конечно приятно сознавать, что кому-то что-то “явно”, но странно, что своим пониманием явности, он не желает делиться, но для чего-то участвует в дискуссии отвечая общими фразами а-ля “ну это же очевидно”.
> Возможно я чего-то не знаю, но из чего следует такое утверждение?
- вопрос против явного
o7412369815963Мы разговаривали в первую очередь не о цифрах, а об архитектуре. В одном наборе тестовых данных Вы находите превосходство подхода, на другом наборе вдруг возражаете: “мы так не договаривались”.
попытка вытянуть факт в другую плоскость (подмена фактов, цифр о которых не разговаривали), “если бы, то кабы…”
o7412369815963Вообще-то с этого “философского” начался весь топик.
Сначала попробуйте сделать опровержение “философскому”: ограничение - есть не удобство.
o7412369815963Полагаю, если я вижу в сообщениях других участников публичной дискуссии неточности, недосказанности и прочие искажения, я всё же имею право отметить это, не так ли?
вы задаете короткий вопрос по монге - мы отвечаем
LexanderОстальные операции умеет делать сам постгрес (на всякий случай, о каких операциях мы говорим?)
pg-json умеет делать меньше 10 операций.
Причем все операции сводятся к преобразованию в строку.
У Монго есть язык запросов.
LexanderВ данном случае о структуре говорить вообще сложно, поскольку между соседними документами коллекции может не оказаться вообще никакого сходства. Если обобщать, то мы можем сравнить коллекцию монго с одноколоночной таблицей реляционной базы, колонка которой имеет тип json (это условное сравнение, поскольку реляционный подход такого не допускает и имеющиеся решения - гибрид с нереляционными). В таком описании слияние двух коллекций есть ничто иное как union.
Впрочем специфика (ограничения) union как раз и показывает ее реляционную сущность. Например, соблюдение порядка следования, кол-ва и типов полей в запросе.
Собственно, у меня даже мыслей не было, что речь может идти о union, если в постановке задачи фигурировали РАЗНЫЕ ПО СТРУКТУРЕ коллекции (таблицы).
LexanderЭто лишь часть картины.
Тело документа, действительно, зачастую - таблица. И хранить ее естественно в табличном виде.
Тем не менее, мы имеем ОДНУ сущность, которую вынуждены разбить на несколько и поместить в разные таблицы.
LexanderДа, сервер приложений может отсутствовать, его функционал может быть вынесен прямо в базу или наоборот в клиент (хотя, имхо, трёхзвенка - куда более общий случай). Модификация этого фрагмента системы в любом случае потребуется, хотя скорее всего она будет и меньше. Для приложений не требующих строгого контроля над структурой данных - этот контроль действительно будет оверхедом, особенно если модификация структуры будет блокирующей. Точно так же, там где он нужен, но отсутствует - ошибки клиента или сервера приложений - породят оверхед по их выявлению и устранению. Что ресурсно дороже - это фактор выбора архитектуры.
Сервер приложений может отсутствовать. Давайте не будем нагромождать частные случаи.
Впрочем, сервер приложений - это тоже еще одно место, где меняется код. Причем этот частный случай вносит еще больше проблем, т.к. при обновлении нужно будет этот самый сервер приложений остановить. Т.е. ваша система не будет работать Н-ное кол-во времени.
LexanderДля больших систем человекочитаемая документация незаменима, но всё же ожидания базы при наличии схемы - описаны языком этой базы и их можно прочитать до документации. В документации - уже смысл этих ограничений.
Уже после первой сотни таблиц (вне зависимости от рода БД) проще смотреть спецификацию, где помимо структуры таблицы (для РБД) описаны все ограничения и преобразования каждого поля. В РБД поле у вас описано в одном месте, ограничения на него - в другом, триггеры на разные события и возможные преобразования значений - в третьем.
Раньше структуру РБД (и остальные плюшки) хоть можно было использовать для контроля правильности данных.
Нынче проверка данных проводится на на всех участках цепи: от клиента до СУБД.
Требования в ПО другие.
LexanderНе совсем понятно. Монго - содержит нефиксированную структуру данных условно неограниченную (технические ограничения есть, но мы до них же не доходим в обоих случаях?). Это разве дорого?
И тем самым потребует больших ресурсов. Дорого.
LexanderЕсли брать сериализацию на уровне клиента и двоичные данные, то да, есть только возможность сохранения произвольной структуры (с некоторыми оговорками про поиск подстроки или соответствия регулярке), если это сохранение, решаемое соответствующими типами данных, то нет, даже наоборот, появляются дополнительные возможности индексации множеств и поиска по такому индексу в виде соответствующих операций с множествами.
Зато напрочь лишают возможности использовать встроенные возможности СУБД.
Начиная с индексов, и заканчивая функциями.
LexanderРазумеется, поскольку одна операция - исключение из обязательности участия в запросах соответствующего столбца (причём я имел в виду ALTER COLUMN … DROP NOT NULL с фоновой очисткой “лишних” значений), после чего клиент может работать с этой базой с незначительным оверхедом по занимаемому дисковому пространству, что на фоне других оверхедов достаточно незначительно, если только мы не обнуляем две трети столбцов. Второй же вариант - это обязательный оверхед на простое при переструктурировании хранилища. По этой и другим причинам я склонен к предпочтению первого варианта (а ведь никто не догадался, почему-то выбросить значение всем показалось сложной задачей) - когда-нибудь может понадобиться и добавить столбец, а без соответствующего резерва оверхед второго сценария неизбежен и это именно то место, где бессхемные и гибридные решения бесспорно выигрывают.
update table set field=NULL
и
alter table drop field
все же разные операции wink
Офлайн
У меня в одном из проектов все данные (разные документы, пользователи, настройки пользователей) были в одной колекции - очень удобно. Отдельные колекции использовались для кеширования, хранения истории, и пр. вспомогательных вещей.
Отредактировано (Фев. 8, 2012 09:29:45)
Офлайн
Пасибо общее направление примерно понятно). Придется действительно все собирать в одну коллекцию по возможности.
Офлайн