Vladimir Kr. wrote: 05 Feb 2018 23:01
при чем здесь производительность, если в nosql атомарности транзакций не гарантируется, это не говоря о референсах (foreign keys), констрейнах, тригерах и прочем.
nosql - очередной узкоспециализированный инструмент с претензией. sql одной ms не ограничивается.
Разница очень простая - в nosql вы просто храните дату а всякие ненормальности решаете в коде. Т.е. просто по другому думаете немного.
это называется альтернативно думаете. Там где нужно foreign keys - в nosql их просто нет, но надо всем об'яснить что они не нужны, атомарности транзакций тоже - "порешаем в коде"!
я не говорю, что все это плохо - но все это "узкоспециализированный инструмент".
Vladimir Kr. wrote: 06 Feb 2018 04:39
это называется альтернативно думаете. Там где нужно foreign keys - в nosql их просто нет, но надо всем об'яснить что они не нужны, атомарности транзакций тоже - "порешаем в коде"!
я не говорю, что все это плохо - но все это "узкоспециализированный инструмент".
Да, именно так. Порешаем в коде. В большенстве случаев foreign keys просто не нужны. В традиционных базах вы бы бы имели таблицы: article, author, journal, comment, article_author, article_journal, article_comment, article_revision, article_reviewers....etc... а в монге свалите в одну коллекцию. И когда вам нужно будет посмотреть сколько статей написал автор вы напишите одну строчку кода. Так же с атомарностью которой обычно достаточно в одном документе - https://docs.mongodb.com/manual/tutoria ... perations/
Ну и т.д. Все эти вещи дают более простой код, более понятную структуру данных которую удобно гонять через API, быстрые операции, отличный скелинг и многое чего.
Vladimir Kr. wrote: 06 Feb 2018 04:39
это называется альтернативно думаете. Там где нужно foreign keys - в nosql их просто нет, но надо всем об'яснить что они не нужны, атомарности транзакций тоже - "порешаем в коде"!
я не говорю, что все это плохо - но все это "узкоспециализированный инструмент".
Да, именно так. Порешаем в коде. В большенстве случаев foreign keys просто не нужны. В традиционных базах вы бы бы имели таблицы: article, author, journal, comment, article_author, article_journal, article_comment, article_revision, article_reviewers....etc... а в монге свалите в одну коллекцию. И когда вам нужно будет посмотреть сколько статей написал автор вы напишите одну строчку кода. Так же с атомарностью которой обычно достаточно в одном документе - https://docs.mongodb.com/manual/tutoria ... perations/
Ну и т.д. Все эти вещи дают более простой код, более понятную структуру данных которую удобно гонять через API, быстрые операции, отличный скелинг и многое чего.
Стенкинг, Вы не можете не знать что сетевые базы данных (то, что сейчас насывается "ноСQЛ") существовали ну уж полтора десятка лет как мин до появления реляционной модели данных. А потом вдруг -бац!- и сетевая модель забилась в щель ("хулиган, забейся в щель - вышли девки на панель!"). А теперь этот труп пытаются реанимировать. Не, есть своя ниша, есть. Но в ОЛТП реляц.модель рулит и будет рулить. А это практич все финансовые операции ("опердень" как говорили в РФ в 90-е).
Как же это вы без гравицаппы пепелац выкатываете из гаража? Это непорядок...
Ion Tichy wrote: 06 Feb 2018 05:22
Вы не можете не знать что сетевые базы данных (то, что сейчас насывается "ноСQЛ") существовали ну уж полтора десятка лет как мин до появления реляционной модели данных.
Этому https://en.wikipedia.org/wiki/Berkeley_DB уже 24 года... В те годы, в силу небогатых вычислительных ресурсов было популярно.
Сейчас популярно, т.к. проще писать код приложений работающих с малонужными данными. Нет ACID и фиг с ним, падает редко, а как упадёт - разберемся, зато релиз быстро выкатили.
Ion Tichy wrote: 06 Feb 2018 05:22
Вы не можете не знать что сетевые базы данных (то, что сейчас насывается "ноСQЛ") существовали ну уж полтора десятка лет как мин до появления реляционной модели данных.
Этому https://en.wikipedia.org/wiki/Berkeley_DB уже 24 года... В те годы, в силу небогатых вычислительных ресурсов было популярно.
Сейчас популярно, т.к. проще писать код приложений работающих с малонужными данными. Нет ACID и фиг с ним, падает редко, а как упадёт - разберемся, зато релиз быстро выкатили.
Есть и более известные. IBM UniVerse. Lotus Notes.
Несите чушь бережно, стараясь не расплескать. Чушь хороша, когда она полная.
У меня душевная травма после использования ЭТОГО на трёх работах. Как так могло получиться, что ОНО стало популярно?! Яркий пример как не надо делать софт для людей.
У меня душевная травма после использования ЭТОГО на трёх работах. Как так могло получиться, что ОНО стало популярно?! Яркий пример как не надо делать софт для людей.
Потому что всегда существовали пользователи и девелоперы (не будем показывать пальцем), которые считали, что большая свалка неструктурированных данных - это круто и за этим будущее. Ну и пытались натянуть эту "дазу банных" на всякие разные явно несоответствующие бизнес процессы.
Но справедливости ради, 4ка была крута для своего времени. Hа R5 как бы всё и закончилось. То что было позже- это реально кошмар и песец.
Несите чушь бережно, стараясь не расплескать. Чушь хороша, когда она полная.
Ion Tichy wrote: 06 Feb 2018 05:22
Стенкинг, Вы не можете не знать что сетевые базы данных (то, что сейчас насывается "ноСQЛ") существовали ну уж полтора десятка лет как мин до появления реляционной модели данных. А потом вдруг -бац!- и сетевая модель забилась в щель ("хулиган, забейся в щель - вышли девки на панель!"). А теперь этот труп пытаются реанимировать. Не, есть своя ниша, есть. Но в ОЛТП реляц.модель рулит и будет рулить. А это практич все финансовые операции ("опердень" как говорили в РФ в 90-е).
Да пофиг на это всё. Если вы не делаете банк конечно или не работаете в гигантах. Поинт что для 95% компаний которые сейчас создаются это всё overkill. Нужна простая light база, нужен простой язык и сервера где-то на digital ocean. Вот я вам за пол-дня день сделаю монго кластер на 10 машин по всему миру ( https://www.digitalocean.com/pricing/ ) 4 GБ / 2 vCPUс / 80 GB SSD за...$200 в месяц тотал. Всё будет работать из коробки, быстро, хорошо.
stenking wrote: 06 Feb 2018 04:58
Да, именно так. Порешаем в коде. В большенстве случаев foreign keys просто не нужны. В традиционных базах вы бы бы имели таблицы: article, author, journal, comment, article_author, article_journal, article_comment, article_revision, article_reviewers....etc... а в монге свалите в одну коллекцию. И когда вам нужно будет посмотреть сколько статей написал автор вы напишите одну строчку кода. Так же с атомарностью которой обычно достаточно в одном документе - https://docs.mongodb.com/manual/tutoria ... perations/
Ну и т.д. Все эти вещи дают более простой код, более понятную структуру данных которую удобно гонять через API, быстрые операции, отличный скелинг и многое чего.
дают более простой. только до первой проблемы, типа а теперь подцепите данные из этого источника. и тут стартаперы начинают понимать нафига вся та наука с консистентным набором, форейн кеями и почему nosql еще 20 лет назад не победил.
в хадупах смотрю мода на здоровый объект в одной записи проходит.
iDesperado wrote: 06 Feb 2018 18:50
дают более простой. только до первой проблемы, типа а теперь подцепите данные из этого источника. и тут стартаперы начинают понимать нафига вся та наука с консистентным набором, форейн кеями и почему nosql еще 20 лет назад не победил.
в хадупах смотрю мода на здоровый объект в одной записи проходит.
Если вы знаете слово хадуп - вам в стартапе делать нечего
iDesperado wrote: 06 Feb 2018 18:50
дают более простой. только до первой проблемы, типа а теперь подцепите данные из этого источника. и тут стартаперы начинают понимать нафига вся та наука с консистентным набором, форейн кеями и почему nosql еще 20 лет назад не победил.
в хадупах смотрю мода на здоровый объект в одной записи проходит.
Если вы знаете слово хадуп - вам в стартапе делать нечего
А что вообще хорошего в стартапе разработчику? Работы валом, всегда на виду, платят мало. А если стартап и пойдет, уволят всех что бы переписать все по-человечески )
Из вашего объяснения я понял что как раз в ноду лезть вообще безумие, т.к. клиенты чисто нищеброды - стартаперы
iDesperado wrote: 06 Feb 2018 18:50
дают более простой. только до первой проблемы, типа а теперь подцепите данные из этого источника. и тут стартаперы начинают понимать нафига вся та наука с консистентным набором, форейн кеями и почему nosql еще 20 лет назад не победил.
в хадупах смотрю мода на здоровый объект в одной записи проходит.
Если вы знаете слово хадуп - вам в стартапе делать нечего
А что вообще хорошего в стартапе разработчику? Работы валом, всегда на виду, платят мало. А если стартап и пойдет, уволят всех что бы переписать все по-человечески )
Из вашего объяснения я понял что как раз в ноду лезть вообще безумие, т.к. клиенты чисто нищеброды - стартаперы
Да я об этом говорю уже 10 лет - каждый язык для определённых компаний/стадий/lifestyle. Java для энтерпрайза. На .NET половина гов сидит а нода это стартапы да. Т.е. вы выбираете язык не по фичам а по тому что вы именно хотите делать в будущем и где работать. Я 15 лет делаю стартапы поэтому после C++ который учил в школе перешёл на PHP/RUBY ну и потом на JS. T.e. все мои скиллы и опыт заточен на то что бы с нуля сделать 5 итераций продукта и развить компанию до 50-100 человек. А там дальше другой мир совсем.
Ничего хорошего в стартапе нет. Это тяжёлая работа за которую недоплачивают. Для разработчика наиболее оптимальной стратегией является работать где-то в ентерпрайзе на С#/Java/Oracle....Или пойти на сити джобс на 7 часовой рабочий день - там всё на MS. Ну и ещё ещё перейти в бекенда на фронтенд - сейчас фронтенд дев нужны всем да и получают в общем уже больше чем бекенд.
Стартапы для тех кто несмотря ни на что готов рисковать. Это другая атмосфера/уровень ответственности/погружение в продукт/другое развитие персонажа ну и конечно надежда на большой экзит.
