Полная Версия: Флуд из темы о вакансии на Java-Junior
| Цитата (Ron @ 17.10.2016 - 20:16) |
| Если у меня данные имеют огромную реляционную ценность (социальная сеть, самый яркий пример), то разумеется я буду использовать реляционную СуБД. А если мне нужно хранить амбулаторные карты пациентов, то выберу Mongo. |
В Facebook, кстати, MySQL используют. Но используют они его как "хранилище пар ключ-значение, никаких join'ов".
_____________
Чатик в телеге
| Цитата (brevis @ 17.10.2016 - 22:06) |
| В Facebook, кстати, MySQL используют. Но используют они его как "хранилище пар ключ-значение, никаких join'ов". |
Но это же ссылка не на официальный источник. =)
Santehnick, ну хочешь делай всё на Монге. Я не считаю что это правильно, скорее наоборот, в большинстве случаев это НЕ правильно. Схему все-равно где-то надо хранить. Джойны все-равно надо как-то делать, и причем через задний проход. Вопрос: зачем использовать инструмент который для этого не подходит? Особенно всюду, где нужно и не нужно. Это с моей точки зрения крайне неразумно.
Я не отрицаю полезности Монги в определенных случаях. Это хорошая СуБД, интересная, под свои задачи даже незаменимая. Когда у нас открытые сущности (требуется schemaless) или огромный объем, особенно данных без связей. Документов. Она и называется Документарная СуБД, что нам как бы намкает на ее предназначение.
Но самое главное далеко-далеко-далеко не каждый проект потребует масштабируемости СуБД, даже сравнительно крупный.
Я не отрицаю полезности Монги в определенных случаях. Это хорошая СуБД, интересная, под свои задачи даже незаменимая. Когда у нас открытые сущности (требуется schemaless) или огромный объем, особенно данных без связей. Документов. Она и называется Документарная СуБД, что нам как бы намкает на ее предназначение.
Но самое главное далеко-далеко-далеко не каждый проект потребует масштабируемости СуБД, даже сравнительно крупный.
| Цитата (jetistyum @ 17.10.2016 - 11:17) |
| Отличная бд для веба, лучше чем реляционные. Веб должен обслуживать любые объемы траффика и решения соответственно должны быть распределенные. |
Вот какое-то очень спорное утверждение. Пробовали сделать проект на чистой монге, очень зае*ались. Реляционная структура нужна для хранения данных, без нее либо "искусственные" реляции уровня приложения, или денормализация и оверхед при хранении данных. Эта бд не совсем для этих целей.
| Цитата (jetistyum @ 18.10.2016 - 09:13) |
| 1. Не использовать джойны, вместо них использовать несколько запросов, как делают например некоторые ORM в php. И это более правильный подход. |
Вот так и делали, но в таком случае растет число запросов растет экспоненциально например при построении грида данных по объектам, чьи свойства хранятся в "реляциях".
| Цитата (Santehnick @ 18.10.2016 - 09:30) |
| Просто многие приходят в монгу и пытаются использовать её таким же образом, каким они использовали рсубд, потом расстраиваются и говорят что у них ничего не получилось |
Этого требует архитектура приложения. Иначе, как я написал - оверхед при хранении и гемор при обновлении денорм. данных
| Цитата (Santehnick @ 18.10.2016 - 12:54) |
| Причем такое количество, что mongo уже обогнала по популярности postgreSQL. |
Может оно так и есть
Тогда дай, плз, какую-нибудь ссылку на хорошее, по твоему мнению, описалово для Монго. Я с этой БД сейчас не работаю, но она есть у нас в проекте. Хоть знать буду, хотя бы примерно, что там косячит серверная команда и почему данные выбираются с такой скоростью, будто там сидит человек и копипастит вручную.
_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL
* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.
* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
Что вы со своими гуглами и фэйсбуками носитесь, у них совершенно другие требования и ресурсы по сравнению с 99.9(9)% проектов 
_____________
Профессиональная разработка на заказ
Я на GitHub | второй профиль
_____________
Профессиональная разработка на заказ
Я на GitHub | второй профиль
Ну так надо же надеяться что проект вырастет в Google или Facebook, как вы непонимаете!!!
http://coub.com/search?q=%D0%BD%D0%B0%D0%B...%B8%D0%B7%D0%BE
Поэтому нужно каждый раз строить немасштабируемый проект на масштабируемой ипочти всегда неудобной СуБД. Потому что построить по-настоящему полностью масштабируемый проект from scratch безумно дорого, и так никто не делает.
http://coub.com/search?q=%D0%BD%D0%B0%D0%B...%B8%D0%B7%D0%BE
Поэтому нужно каждый раз строить немасштабируемый проект на масштабируемой и
Здесь расположена полная версия этой страницы.