Подскажите, кто знает! Когда переходишь на новую строку, таб применяется только полке того как завершишь строку ";". В 2017 жмешь ентер — уже с табом на новой строке....
Что значит большая? Скорость вставки/обновления данных в монге постоянная. Она не быстрее, чем в СКЛ, она относительно ПОСТОЯННА. Если вы используете монго как мастер-бд, то имейте ввиду, что с накоплением данных, поиск по ним будет усложняться. Я советую использовать монгу, как хранилище для сырых данных с добавлением/обновлением и простым поиском.
Я решаю этот вопрос, выделением частей объекта. Т.е. у одна сущность может храниться во множестве коллекций. Как я уже писал, это сырые данные. Для пользователей эти данные коммитятся в другую базу, в которой и уже работает поиск и т.п.
Как бы правильно все говорите… И все логично рассуждают тут, прям сложно не согласиться, что NoSQL — Г… НО(это именно "но", а не продолжение предыдущего слова)! Лучше пользоваться той технологией, которой умеешь хорошо пользоваться! Я, например, умею очень хорошо пользоваться документами. РСУБД я уже подзабыл за 8 лет… Я помню, что когда начинал изучать документы, тоже не мог в голове уложить, как с помощью "ЭТОГО" можно что-то решить!? Прям рассуждал как все… Но прошло время и стало все понятно. Я желаю всем здесь собравшимся, хотя бы в качестве факультатива применить на небольших проектах сначала и другие технологии, например документоориентированные СУБД, сейчас их палным-пално всяких разных (MongoDB, Elasticsearch, in-memory документы: Tarantool, Apache Ignite и т.д.)
Ну ничего себе! Документы пустили корни в РСУБД! Что бы это значило? Я думаю это значит, что документы — это очень удобно и глупо ими не пользоваться! Но все же считаю, что JSON-столбцы, тем более с индексами — это костыль...
Отнюдь… Я как-раз таки выбрал именно монгу для хранения таких данных. Моя ORM прекрасно работает с множественными БД, поэтому никаких проблем не испытываю. Почему именно Монго? Я слишком привык к документам, уже и не могу понять как можно хранить данные в таблицах, это не очень удобно, хотя понадежнее с точки зрения целостности и последующей обработки… Но с этими проблемами еще не сталкивался. И второе, Монго имеет достаточно постоянное время вставки, а так же простую репликацию и шардинг.
Хайп, не лучшый механизм выбора решения. Мне вот потребовалось 8 лет, чтобы осознать что, как и когда надо использовать… Тоже на этой хайпе был сначала!
Совершенно верно! Я его тоже не использую, как и любые ее возможности поиска. Вообще говоря, монга не очень для каких либо деяний. Я за документы! Храню в ней сырые данные, потом заливаю их в другие БД, которые уже и используются для частых запросов. Все сугубо индивидуально от задачи.
Например, из вышеприведенного примера можно собирать из монги или другой БД сырые данные, класть их в описанный документ. Я так и поступаю. Там и статистику можно закомитить и что угодно вообще! Без отдельного warehouse, ETL и тому подобного… Схема — всему голова! И правильное применение.
Конечно, все так. Но Вы же уже считали эту статистику. Тогда берете и юзаете в той же монге Aggregation Framework… В общем и целом за 10 лет практики с NoSQL я не столкнулся с какими либо подобными задачами. Все так же как и везде… Просто я стараюсь при проектировании учесть многое, тем самым сократив расходы на стандартные функции, а не стандартные решаю так же как все...
Вы верно заметили, что NoSQL — это не SQL! Мне не понадобится, т.к. я это не проектировал. Ну а все же, если понадобится, я либо создам новую коллекцию и буду писать туда статистику обращений, либо заюзаю колоночную БД для такой записи.
Если ПО разрабатывается по принципу, "а вдруг понадобится", то следует использовать РСУБД!
В статье было уже сказано, что транзакции поддерживаются с версии 4.0. Что касается достоинств и недостатков, тут нужно понимать с какой позиции Вы смотрите. Если с позиции реляционных БД, но недостатков, наверное, можно много насчитать, если с позиции Key-Value, то же самое, например скорость и т.д. Примитивно преимущество любой СУБД относительно другой, заключается в способе хранения данных, например, key-value для быстрого доступа по ключу, колоночные, для быстрых вставок, документоориентированные для хранения больших структур, а реляционные для удержания целостности данных и легкого построения запросов.
Посмотрите язык запросов Elasticsearch, я думаю, большое количество людей когда увидят как выглядит несложный запрос в этой БД, заплюют ее. НО! Просто так ничего не происходит. Во всякой особенности той или иной БД есть смысл.
Выше nvv правильно заметил, что в NoSQL нужно все контролировать и учитывать. Для РСУБД этот контроль на себя берет сама СУБД.
Итак, достоинство. В MongoDB можно реализовать сложную схему данных с массивами, вложенными объектами, вложенными массивами вложенных документов с вложенными массивами вложенных документов и т.д. Это дает возможность в итоге безо всяких джойнов достать все и сразу. Представим, что у Вы разрабатываете интернет-магазин, и проектируете страницу товара, тогда у вас будет документ товара, в котором будет все, что есть на этой странице (грубо): производитель с логотипом, вся галерея картинок, все характеристики, отзывы с постраничной отдачей, наличие и т.д. И все это Вы загрузите из одного документа, т.е. 1 запрос без каких либо джойнов. Недостаток же заключается в сложности проектирования, поддержания целостности и разработки.
Развлечение такое, не более. Ну и задача есть, решить надо...
Ожидаемый комментарий...
Вы совершенно правы! Тут надо пометку сделать, что для простых запросов...
Подскажите, кто знает! Когда переходишь на новую строку, таб применяется только полке того как завершишь строку ";". В 2017 жмешь ентер — уже с табом на новой строке....
Канеш! Я уже кодю на ней под Win7 Embedded x86 в vbox :)
У меня ничего не удаляется. Есть поле Deleted. Сложнее, зато надежнее!
Что значит большая? Скорость вставки/обновления данных в монге постоянная. Она не быстрее, чем в СКЛ, она относительно ПОСТОЯННА. Если вы используете монго как мастер-бд, то имейте ввиду, что с накоплением данных, поиск по ним будет усложняться. Я советую использовать монгу, как хранилище для сырых данных с добавлением/обновлением и простым поиском.
Я решаю этот вопрос, выделением частей объекта. Т.е. у одна сущность может храниться во множестве коллекций. Как я уже писал, это сырые данные. Для пользователей эти данные коммитятся в другую базу, в которой и уже работает поиск и т.п.
Как бы правильно все говорите… И все логично рассуждают тут, прям сложно не согласиться, что NoSQL — Г… НО(это именно "но", а не продолжение предыдущего слова)! Лучше пользоваться той технологией, которой умеешь хорошо пользоваться! Я, например, умею очень хорошо пользоваться документами. РСУБД я уже подзабыл за 8 лет… Я помню, что когда начинал изучать документы, тоже не мог в голове уложить, как с помощью "ЭТОГО" можно что-то решить!? Прям рассуждал как все… Но прошло время и стало все понятно. Я желаю всем здесь собравшимся, хотя бы в качестве факультатива применить на небольших проектах сначала и другие технологии, например документоориентированные СУБД, сейчас их палным-пално всяких разных (MongoDB, Elasticsearch, in-memory документы: Tarantool, Apache Ignite и т.д.)
Ну ничего себе! Документы пустили корни в РСУБД! Что бы это значило? Я думаю это значит, что документы — это очень удобно и глупо ими не пользоваться! Но все же считаю, что JSON-столбцы, тем более с индексами — это костыль...
А зачем мне хранить из в JSON-столбцах, если я могу их хранить в документах? Кстати, индексы умеют строить РСУБД для таких столбцов?
Отнюдь… Я как-раз таки выбрал именно монгу для хранения таких данных. Моя ORM прекрасно работает с множественными БД, поэтому никаких проблем не испытываю. Почему именно Монго? Я слишком привык к документам, уже и не могу понять как можно хранить данные в таблицах, это не очень удобно, хотя понадежнее с точки зрения целостности и последующей обработки… Но с этими проблемами еще не сталкивался. И второе, Монго имеет достаточно постоянное время вставки, а так же простую репликацию и шардинг.
Не встречал… Поищите, наверняка есть. Могу только советы дать из личного опыта
Хайп, не лучшый механизм выбора решения. Мне вот потребовалось 8 лет, чтобы осознать что, как и когда надо использовать… Тоже на этой хайпе был сначала!
Совершенно верно! Я его тоже не использую, как и любые ее возможности поиска. Вообще говоря, монга не очень для каких либо деяний. Я за документы! Храню в ней сырые данные, потом заливаю их в другие БД, которые уже и используются для частых запросов. Все сугубо индивидуально от задачи.
Например, из вышеприведенного примера можно собирать из монги или другой БД сырые данные, класть их в описанный документ. Я так и поступаю. Там и статистику можно закомитить и что угодно вообще! Без отдельного warehouse, ETL и тому подобного… Схема — всему голова! И правильное применение.
Конечно, все так. Но Вы же уже считали эту статистику. Тогда берете и юзаете в той же монге Aggregation Framework… В общем и целом за 10 лет практики с NoSQL я не столкнулся с какими либо подобными задачами. Все так же как и везде… Просто я стараюсь при проектировании учесть многое, тем самым сократив расходы на стандартные функции, а не стандартные решаю так же как все...
Очень сомнительное утверждение. А Вы уже использовали монгу и другие подобные системы? В монге есть курсоры
Вы верно заметили, что NoSQL — это не SQL! Мне не понадобится, т.к. я это не проектировал. Ну а все же, если понадобится, я либо создам новую коллекцию и буду писать туда статистику обращений, либо заюзаю колоночную БД для такой записи.
Если ПО разрабатывается по принципу, "а вдруг понадобится", то следует использовать РСУБД!
Наоборот, проще на РСУБД накидать прототип. Господа, боюсь, вы не совсем верно понимаете суть свободной схемы, см. мои предыдущие комментарии.
В статье было уже сказано, что транзакции поддерживаются с версии 4.0. Что касается достоинств и недостатков, тут нужно понимать с какой позиции Вы смотрите. Если с позиции реляционных БД, но недостатков, наверное, можно много насчитать, если с позиции Key-Value, то же самое, например скорость и т.д. Примитивно преимущество любой СУБД относительно другой, заключается в способе хранения данных, например, key-value для быстрого доступа по ключу, колоночные, для быстрых вставок, документоориентированные для хранения больших структур, а реляционные для удержания целостности данных и легкого построения запросов.
Посмотрите язык запросов Elasticsearch, я думаю, большое количество людей когда увидят как выглядит несложный запрос в этой БД, заплюют ее. НО! Просто так ничего не происходит. Во всякой особенности той или иной БД есть смысл.
Выше nvv правильно заметил, что в NoSQL нужно все контролировать и учитывать. Для РСУБД этот контроль на себя берет сама СУБД.
Итак, достоинство. В MongoDB можно реализовать сложную схему данных с массивами, вложенными объектами, вложенными массивами вложенных документов с вложенными массивами вложенных документов и т.д. Это дает возможность в итоге безо всяких джойнов достать все и сразу. Представим, что у Вы разрабатываете интернет-магазин, и проектируете страницу товара, тогда у вас будет документ товара, в котором будет все, что есть на этой странице (грубо): производитель с логотипом, вся галерея картинок, все характеристики, отзывы с постраничной отдачей, наличие и т.д. И все это Вы загрузите из одного документа, т.е. 1 запрос без каких либо джойнов. Недостаток же заключается в сложности проектирования, поддержания целостности и разработки.