Говорят, что вакцины стали жертвами собственной эффективности. Будто если бы мы видели, как странновато одетый кучер раз в неделю забирал бы трупы нескольких соседей, умерших, как и десятки до них, довольно неприятной смертью, может, и вакцинировались бы охотнее.
Я не ученый вирусолог/эпидемиолог/фармацевт, я зарабатываю себе на хлеб тем, что пишу программы. Иногда мне кажется, что делаю это довольно успешно. Сегодня в очередной раз я услышал фразу, что привел в эпиграфе, а вчера в баре под укоризненные взгляды друзей рассказывал, как я отбился в проекте от использования какой-то нереляционки и у меня в голове щелкнуло и я сел набирать этот текст.
С середины прошлого века мы работаем над реляционными базами данных. И они прекрасны. Но сейчас все чаще любят использовать NoSQL всех видов и мастей. И они иногда неплохо ложатся и затыкают собой какое-то мелкое место в проекте. Если я ценю свои данные и мне нужна какая-то надежность, то мне нужны ACID гарантии. Если это всего лишь кеш, данные из которого нужны чтобы ускорить приложение то я с радостью возьму Redis или аналоги. Ведь если он упадет или данные рассогласуются я смогу их восстановить из нормальной базы.
Справедливости ради часть ACID гарантий завезли уже и в некоторые нереляционки, где-то их даже включили по умолчанию.
Несколько раз мне приходилось расследовать инциденты связанные с битыми данными в NoSQL базах или даже просто в самописных хранилищах поверх файловой системы. Это был ад. Тот ад, который я больше никогда не хочу видеть на этой Земле. А эти инциденты повторялись. Работая с реляционными базами каждый такой инцидент повторялся лишь единожды, причиной его становился забытый constraint или внешний ключ или пачка операций не была завернута в транзакцию. В любом случае проблема решалась одним из инструментов и больше не воспроизводилась.
Скорее всего есть те, кто не собирал по столу вытекшие глаза после расследования инцидента связанного с битыми данными. Они скажут, что ACID гарантии избыточны. Так эти гарантии стали жертвами собственной эффективности. Но, кстати, даже тут современным СУБД есть что ответить: да из коробки они заточены на поддержание данных в максимальной консистентности, но если вам это не нужно, то у вас есть широкий набор инструментов, чтобы эти гарантии ослабить в одном конкретном узком месте, оставляя их в другом.
Сегодня с утра, я навесил хитрый constraint на свою любимую PostgreSQL базу, он обеспечивают довольно хитрую составленную из нескольких колонок и пары булевых свойств гарантию. Эту же гарантию обеспечивает c# код средней мутноватости на уровне бизнес логики, а чтобы он не поплыл он смазан хорошим слоем юнит-тестов, которых самих особо не рассмотришь за слоем моков.
Только вот код бизнес логики будет меняться еще десятки раз, да и собрать его по десятку сервисов, каждый из которых аж до тошноты соответствует букве S из SOLID будет непросто. А этот constraint занимает всего пару строк великолепного SQL. Который кое-как читается даже людьми с ним сильно не знакомыми. Хотя так ли их много в сообществе разработчиков? Все-таки, как не крути NoSQL-мыслевирус еще не засел так глубоко и большинство все-таки на каком-то уровне SQL выживают.
А ведь SQL потрясающий язык, может у меня идет сумасшедшая профдеформация, но я иногда думаю, что мир был бы лучше, если бы SQL учили все. Когда смотрю какой-то закрученный детектив где ФБР не может найти серийного убийцу действующего в тех-то штатах в такие-то годы я понимаю, что по факту имей мир SQL интерфейс, то это был бы всего лишь один простой SQL запрос с несколькими INTERSECT операторами.
А вот еще... Необходимость описывать схему и структурировать данные.
Тут есть два варианта: если вы пишете на строго типизированном языке, то вряд ли ваши данные, которые вы хотите складывать в свою базу такая уж свалка. Потому что если там прямо совсем треш, то как вы его получили? Ну ладно, даже если вы его как-то получили, то что вы с этими данными потом собираетесь делать? Как вы будете обрабатывать совсем уж не структурированный поток данных. Скорее всего какая-то структура данных у вас таки есть. Если же вы пишете на языке без строгой системы типов, то после того как я понимающе и соболезнуя похлопаю вас по плечу, я все равно спрошу у вас: А как вы собираетесь эти данные обрабатывать?! Ну то есть типов может и нет у вас в языке, но они есть в компьютере под капотом как не крути и очень сложно писать код, который работает совсем уж с не определенными типами.
И я действительно готов поверить, да что там готов, у меня у самого в одном из пет-проектов есть необходимость хранить свалку HTML. Возможно здесь бы и легла лучше какая-то NoSQL база, но у меня уже в проекте была реляционка. И знаете что? Она вполне себе справилась с этой задачей, даже не особо чихнув или подавившись.
Я знаю, что все основные СУБД уже поддерживают JSON как один из основных типов. То есть, если где-то в проекте вам таки нужно устроить свалку из черт знает чего, то почти каждая современная база даст это сделать. Более того, по черт знает чему можно построить даже индекс или заставить валидировать при вставке на соответствии схеме.
А еще тулинг. С инструментами для баз данных часто все хуже чем с инструментами для .net, java, python etc, но насколько же они несравнимо лучше чем та дрянь, что существует для нереляционок. А еще не для всех нереляционок вообще есть что-то внятное, что позволит нормально посмотреть на свои данные. Более того, за почти 70 лет, что активно развиваются реляционные базы инструменты успели не только появится, их успели отладить, на StackOverflow успели задать вопросы и получить ответы. Разрабатывая проект с реляционной базой под капотом вообще не получится себя почувствовать первопроходцем, ведь первая же ссылка в гугле будет отвечать на ваш вопрос. Даже если это не сама база, а что-то вокруг нее: инструменты для репликации, бекапов, мониторинга или еще черт знает чего. Да даже ORM последнее время стали совсем не дурны.
По SQL даже книжки есть хорошие, причем их даже много. Многие из них издаются уже с десяток лет и там исправлены основные неточности. Вряд ли вчера появившаяся нереляционка обещающая, непонятно как измеренный потрясающий performance, сможет таким похвастаться еще лет 20. А протянет ли она 20 лет?
При приеме на работу сложно требовать знания конкретной нереляционки. Их многовато стало последнее время. С другой стороны все SQL базы похожи между собой сильнее чем нереляционки между собой. И это значит, что вам будет легче нанимать людей с их знанием. Более того общаться в команде будет легче. И выше будет вероятность, что кто-то из команды уже решал эту задачу ранее и получил какой-то практический опыт. Возможно даже негативный. Любят как-то недооценивать этот момент. Но при работе с NoSQL, может это только у меня так было, сравнительно глубоко знал особенности этих баз и был вынужден постоянно объяснять термины, нюансы и edge-кейсы остальным.
Выводы
Я иногда использую NoSQL базы. Но делаю это в крайнем случае.
Сначала я раскладываю все в реляционку. Это решение по умолчанию. Если что-то где-то оказывается неудобно или тормозит, я могу ослабить гарантии или денормализовать данные. Обычно этого хватает. Когда этого не хватает, то для конкретного случая отлично подходят нереляционки. Но не стоит переводить на них весь проект.
Инструменты для NoSQL оставляют желать лучшего, а для некоторых задач отсутствуют.
Про SQL-базы проще разговаривать в команде, проще нанимать людей, проще искать ответы.
Дисклеймер: Статья имеет легкий провокационно-юмористический налёт.
И да. Дисклеймеры обычно пишут в начале.
Комментарии (41)
SergeKh
21.12.2021 16:56+1В разных проектах разные требования. Бывает кода подходит SQL, бывает когда NoSQL. Не нужно пытаться делать лишних обобщенией "всем нужен только SQL, NoSQL сжечь", или наоборот.
fkafka
21.12.2021 17:52+12Автор, по крайней мере, сравнил NoSQL всего лишь с антивакцинаторством, а не сразу с нацизмом :))
FanatPHP
22.12.2021 09:14+2Требования разные, но большую часть NoSQL действительно сжечь, просто за ненадобностью.
Этим словом называют то, что либо совсем не БД (а кэш), либо JSON-переросток, который нежизнеспособен сам по себе, без реляционной поддержки, и сейчас занял подобающее место - в виде специального типа поля в нормальных БД.
Отаются только отдельные случаи типа key-value и колоночно-ориентированных БД, но они настолько разные, что им тем более не нужен хайповый buzzword чтобы загрести их все под одну гребенку.
dim_s
22.12.2021 12:47Если вы не наблюдали или не видели таких систем, это не значит что их нет. Я в своей практике последние 5-6 лет всё чаще вижу системы, которые полностью обходятся без реляционной БД. И тут не важно, комбинируют всё и вся, и key-value, и json (bson) и другие подходы. Тем более это же всё не только про хранение, но и про относительно (обычных классических БД) горизонтальное масштабирование из коробки, доступный и понятный шардинг и многое другое. Это могут обеспечить на хорошем уровне только крупные корпоративные БД типа Oracle для реляционных баз.
P.S. Да, очень много специалистов, которые неправильно работают с NoSQL системами, пытаются туда перенести свой опыт работы с SQL, либо радикально превращают в свалку данных, думая что так и надо.
FanatPHP
22.12.2021 13:56+3Та наблюдали-то как раз многие. Один из примеров и приведён в моем комментарии. Наблюдать мало, надо чтобы потом оно еще и работало. А с этим обычно хуже.
Ну и опять же, каждое специализированное решение надо рассматривать отдельно, а не пихать все в один зонтичный buzzword. И окажется, что все специализированные системы хранения прекрасно дополняют, а не заменяют нормальную БД.
dim_s
22.12.2021 18:40Ну я разрабатывал и наблюдал как раз рабочие системы без реляционных БД. Всё прекрасно работает, в том числе на больших нагрузках и еще и масштабируется. Конкретно это всякие документно-ориентированные и колоночные бд типа MongoDB, ElasticSearch, Cassandra. Да это были не финансовые приложения, конечно, всякие контентные системы, что-то похожее на социальные сети, CRM, и т.п.
P.S. По поводу примера, если уж разработчики криво спроектировали модель данных для MongoDB, это не значит что она не работает, а заголовок отдает желтушностью и кликбейтом. Я завтра пойду, криво спроектирую модель данных для Postgresql, а потом напишу статью, какой pgsql плохой и не позволяет мне решить какие-то критические проблемы - и напишу статью с заголовком "Почему вы никогда не должны использовать PostgreSQL"
FanatPHP
23.12.2021 08:36А что, так можно было? В смысле, спроектировать "прямую" модель данных для Монги? В смысле - нормальную реляционную, с уствновлением нужных связей, о которых говорится в статье? И даже перекладивание контроля целостности с БД на программиста - тоже не помеха?
А можете привести контрпример? Ну в смысле основную БД приложения на Монге, спроектированную "правильно"?
kai3341
21.12.2021 20:15+5Ловите плюс! Отличная статья, пытаюсь то же самое доносить до людей
Небольшая претензия к форме, а не содержимому
Только в первом абзаце у вас с запятыми полнейший абзац. Пожалуйста, поправьте. Надеюсь, удалю этот спойлер через пару часов
Дополню одним тезисом. Мне иногда ссылаются на Google, который в некоторых своих проектах использует нереляционки, так как у них лучше обстоит с шардингом. Мой ответ Вы не Google им почему-то непонятен
Дополню за JSON в базах данных. Забавно, но тут возможны 2 разных JSON :) Обо всём по порядку:
JSON в качестве хранилища. Тема неоднозначная. Допустимо там, где мы данные не обрабатываем средствами СУБД. Как только нам прижало строить индекс по JSON -- рефакторить структуру БД надо было вчера
Преобразование в JSON во время SELECT. А вот тут я нашёл много вкусного в JSON_ARRAYAGG и JSON_OBJECTAGG. Как мне -- это удобный способ выжать максимум как из гарантий реляционной структуры, так и из удобства и производительности чтения
podkolzzzin Автор
21.12.2021 21:12+1Был интересный момент, когда Google понял, что не способен нанимать инженеров, что способны писать прикладной код распределенных систем совсем без гарантий. Даже google.
Кстати, помимо того же JSON многие реляционные базы поддерживают и разного рода объекты: массивы, словари или просто объекты с наборами полей.
P.S. Постарался поправить пунктуацию.
geher
21.12.2021 20:55-2Nosql - это не только json. И видов nosql баз даже не два. И каждый под свою задачу.
Второй вопрос - взаимопроникновение моделей баз данных, когда над nosql строят вполне себе реляционную конструкцию (как в Cache), а в реляционку впихивают нечто графовое, документное или еще какое (в том же postgresql имеется возможности как минимум документной nosql базы данных).
Так что в простом противопоставлении реляционной и nosql модели (особенно без уточнения, какой именно nosql модели) становится все меньше смысла, хотя и раньше его было совсем немного.
Все-таки выбор субд определяется не всякими красивыми словами про ACID и SQL, а требованиями проекта.
podkolzzzin Автор
21.12.2021 21:18+1Результатом анализа требований проекта может быть понимание того, что для него целостность данных критична.
Как правило, внутри каждого проекта есть данные целостность которых критична. Часто бывает, что целостностью каких-то данных можно принебречь. Если эта возможность как-то развяжит инженерам руки, то можно будет ею воспользоваться.
Если же можно получить и достаточную производительность и целостность всех данных, то лучше получить и то и другое. К тому же снизив сложность найма и упростив общение.
geher
23.12.2021 23:49+1Как правило, внутри каждого проекта есть данные целостность которых критична.
Но бывает, когда другие моменты настолько важнее целостности, что ее контролем на уровне СУБД можно пренебречь.
Например, иногда структура данных не укладывается адекватно в реляционную модель. Втиснуть-то можно все, но результат превращается в неудобоваримую отвратительно поддерживаемую нелогичную дичь. Например, сложные графы можно хранить в реляционной СУБД, но простые по идее задачи превращаются в зубодробительные запросы, полные финтов ушами.
С другой стороны некоторые nosql СУБД предоставляют свои средства для контроля целостности данных (та же IRIS от Intersystems).
Если же можно получить и достаточную производительность и целостность всех данных, то лучше получить и то и другое.
А если нельзя ?
К тому же снизив сложность найма и упростив общение.
Кстати о найме и упрощении общения. Казалось бы, везде SQL, а начнешь на практике что-то делать, так сразу вылезают заметные отличия, например, с именованием типов данных. Причем порой самые неожиданные отличия. А если забираться в дебри расширений языка от разных производителей СУБД...
podkolzzzin Автор
24.12.2021 12:24Но бывает, когда другие моменты настолько важнее целостности, что ее контролем на уровне СУБД можно пренебречь.
Так действительно бывает. Можно попробовать ослабить гарантии в конкретной таблице, возможно этого будет достаточно. Если этого окажется недостаточно, то можно взять для этого конкретного набора данных какую-то более подходящую базу.
Втиснуть-то можно все, но результат превращается в неудобоваримую отвратительно поддерживаемую нелогичную дичь.
Эти данные так же можно отложить в отдельную СУБД, более подходящую.
Но скорее всего в проекте есть еще и более приземленные данные. Их все еще можно хранить в традиционной базе RDBMS.
А если нельзя ?
Нужно до этого дайти. Найти в чем затык. Посмотреть можно ли это просто решить средствами существующего инструмента. Если нет, то применить в этом месте более подходящее.
А если забираться в дебри расширений языка от разных производителей СУБД...
Дебри всегда дебри. Часто даже не больших проектов в них лезть не приходится. Если уж пришлось, то вероятно и при использовании другого инструмента это были бы уже дебри.
Norgorn
22.12.2021 11:47Не понимаю, за что вас минусят.
Вот есть колоночные базы, зачем они вообще нужны? Очевидно, чтобы читать данные по всем строкам из одной колонки быстро (последовательно). Зачем нужны документные базы? Тоже очевидно, чтобы разом читать целый документ. Есть у них недостатки? Конечно есть, но есть и сценарии, где по-другому будет просто хуже.
А бывают ещё аналитические базы (типа Кликхауса или Друида), использовать вместо них реляционную на нормальной нагрузке просто не прокатит.
В итоге видим, что действительно сравненивать nosql и sql "в целом" абсолютно бессмысленно, они подходят для разных задач. Использовать условную Монгу там, где нужны гарантии и надёжность реляционных баз - глупо и больно. Но точно так же глупо использовать ПГ там, где он не подходит.
FanatPHP
22.12.2021 14:07+2Так об этом и речь, что на волне nosql хайпа были реальные попытки использовать недобазы в качестве основного хранилища приложения. О чем как раз и написана статья, под который вы оставляете свой комментарий. О том что критичные для работы приложения данные хранятся не в БД а в модных побрякушках.
При этом никто и не говорит, что системы кэширования, аналитики или полнотекстового/фасетного поиска не нужны. Нужны. Просто надо понимать, что используются они для организации сервисных функций, а не хранения основных/критичных данных приложения. Сам же термин noSQL, который собрал, как в Ноев Ковчег, каждой твари по паре, как бы намекает на попытку поставить на одну ступеньку этот зоопарк и базы данных.
В пустыне встречаются осёл и прапорщик.
Осёл:
— Ты кто?
Прапорщик посмотрел по сторонам, никого:
— Я офицер, а ты?
Осел посмотрел по сторонам:
— Тогда я — лошадь.Вот и с noSQL так же.
vagon333
21.12.2021 22:22+3Консультирую стартап, который решил пере-изобрести стандарт схемы американского банковского кредитования (MISMO). Получилось недоразумение. Обсуждаем переход на SQL.
Часто вижу сценарий:
- революционные идеи (в этой компании описание схемы через Graph DB + JSON),
- корректировка фантазий реалиями (в этой компании изобретение превращается в рассыпающиеся кусочки классов)
- переход на структурированные данные и обычную базку.
OlegZH
21.12.2021 22:26+1Интересно, а можно ли сделать так, чтобы всю логику работы системы можно было бы описывать только на сервере?
Берём СУБД, реализуем некоторую модель данных, прописываем ограничения, задаём триггеры. Над моделью данных строим модель конечного приложения. С каждой моделью данных можно связать несколько моделей приложений (в зависимости от типов задач). В то же время у пользователя имеется своя собственная модель — модель пользовательского интерфейса (при этом, пользователь сам может выбирать модель к некоторму приложению в зависимости от самих решаемых пользователем задач).
Получаем трёхзвенную архитекутру. Модель данных и модель пользовательского интерфейса вполне могут управляться на основе реляционной модели, а, вот, модель приложения вполне может управляться NoSQL. Промежуточная модель, фактически, осуществляет отображение многие-ко-многим, поэтому здесь нужно иметь большую свободу действий.
cross_join
22.12.2021 19:11Не только можно, это очень популярная архитектура примерно с середины 1990-х годов - использование процедурного расширения SQL СУБД в качестве сервера приложений с тонким клиентом. Примеры, навскидку, "Босс-компания" (не путать с "Босс-корпорацией") и Ultima-Seller, перетекший в открытый код. Подробнее по ссылке.
froller
22.12.2021 21:18Ну, существуют же DBD-приложения, где UI -- это морда для SELECT/CALL. Тот же Kondor+, например.
Клиентский доступ к данным только через вьюхи и хранимки. Вся бизнес-логика в хранимках и описана.
cross_join
21.12.2021 22:32+5Основная проблема того, что называют NoSQL - в непроработанности моделей данных. Зная, что практически все они были известны в дореляционную эпоху (к моменту "великого спора" Кодда с Бахманом их было известно более 40), можно с основанием говорить о неполноте и даже о неполноценности.
Полнота SQL иллюстрируется просто. SQL-запрос над множеством возвращает множество, которое может быть обработано следующим SQL-запросом или подзапросом. В NoSQL даже созданные сверху SQL-подобные языки так не могут, и проблема не в языках, а в модели данных и замкнутости операций. Для выборки, которую не обработать одним запросом, нужно писать программу (здравствуй, Питон). Исключение - KeySQL, где эта теоретическая проблема решена.
dim_s
22.12.2021 09:06+2Для начала бы рассказали, какого типа NoSQL системы вы имеете ввиду - документно-ориентированные, колоночные, графовые, key-value и т.д. И с какими из них работали. А то похоже на то, что вы поделили всё на черное (NoSQL) и белое (SQL).
P.S. А вижу в тегах MongoDB... ну тогда советую попробовать и другие nosql системы.
froller
22.12.2021 21:35Согласен.
Например Paradox - покойник - вполне себе реляционный, хоть и не умеет SQL. :)
hard_sign
22.12.2021 09:53+3Всё так, но вы немного путаете тёплое с мягким.
ACID-гарантии дают монолитные базы, т. е. базы, работающие на одном сервере. Проблемы с целостностью начинаются на распределённых платформах. Но вообще говоря из распределённости непосредственно не следует нереляционность.
Почему MongoDB, Cassandra и стопиццот других платформ не реляционные? Потому, что реализовать SQL на распределённой системе сложно. То есть неполноценный интерфейс – это плата за распределённость.
Тем не менее, есть и реляционные распределённые СУБД – например, Cockroach. Он вроде как декларирует ACID, но ценой производительности.
Есть в природе и нереляционные монолитные СУБД. Например, GT.M. Зачем их использовать – загадка, потому что SQL реально удобен.
Есть, конечно, и распределённые реляционные СУБД с полноценным ACID – Greenplum, Teradata, Microsoft PDW... Но тут мы уходим вбок по третьей оси – OLTP/OLAP :)
sgjurano
22.12.2021 10:18+2Здесь ещё хочется добавить что сам по себе акроним ACID — очень странный, у него нет строгого смысла за пределами интуиции "как в популярных RDBMS".
В случае Distributed SQL баз (тот самый Cockroach, YugabyteDB, TiDB и прочие) обычно говорят более строго про strict serialisability — эквивалентность наблюдаемого состояния какому-то серийному исполнению, а так же упорядочивание неконкурентных операций в соответствии с их порядком в реальном времени.
hard_sign
22.12.2021 10:23+2О да, если начать детально разбираться, кто что имеет в виду под тем или иным термином, то можно заниматься этим всю оставшуюся жизнь :)
dim_s
22.12.2021 12:43+1Для nosql и распределенных баз придумали BASE:
базовая доступность (англ. basic availability) — каждый запрос гарантированно завершается (успешно или безуспешно).
гибкое состояние (англ. soft state) — состояние системы может изменяться со временем, даже без ввода новых данных, для достижения согласования данных.
согласованность в конечном счёте (англ. eventual consistency) — данные могут быть некоторое время рассогласованы, но приходят к согласованию через некоторое время.
DX28
22.12.2021 12:48При возможности выбора СУБД на этапе проектирования проекта надо все таки рассматривать как SQL так и NoSQL варианты. Чтобы потом не пришлось "Совой о пень".
Вот пример из текущего проекта - данные(сотни миллионов строк) содержатся в JSON полях (размер которого бывает до нескольких Мб, неструктурированное дерево с десятком уровней). Изначально был выбран Postgres - ну а потому что знали его больше. А теперь поняли всю глубину промаха - суть еще в том что данные постоянно апдейтятся - миллионы строк в день. А что такое апдейт jsonb поля? это сложный процесс по распаковке в память из xact хранилища, поиску ключа + mvcc ... Параллельно работает до 1000 пользователей. А наши дата-саентисты еще это все в hadoop пытаются запихнуть.
FanatPHP
22.12.2021 14:15И что решили в итоге? Таки нормализовать это jsonb гуляй-поле? Или вывести его на новую высоту и взять сервис, который из одного джейсона и состоит?
DX28
23.12.2021 07:24+1Пока смотрим в сторону колоночных СУБД.
Анализируем каждую на предмет производительности в нашем случае.
FanatPHP
23.12.2021 08:34+3Эээ... Честно говоря, я вообще не понимаю, как можно "неструктурированное дерево с десятком уровней" конвертировать в колоночную, т.е. строго структурированную БД.
Видимо, данные изначально были вполне структурируемые, но их, как это обычно бывает, поленились нормализовать :)
В любом случае, после сруктуризации стоит посмотреть и на исходный Пострес. Поскольку при нормальной структуре эти миллионы апдейтов не составят для него проблемы.
cross_join
22.12.2021 19:40+2Принцип garbage in - garbage out никто не отменял. Если вы не можете контролировать чистоту данных при записи в БД, то вам придется делать это потом, при каждом запросе на их извлечение из БД. Это раз. Для подхода "храним все, что прилетает" у вас нет разделения "болота данных" и витрин, это два. 1000 пользователей никогда не работают одновременно над всеми данными, это три.
robo2k
22.12.2021 15:46Не очень понимаю, неужели в серьезных проектах никогда не встречаются случаи, когда приходится работать с множеством разноплановых данных, как то их фильтровать и обрабатывать? SQL абсолютно беспомощен, когда у данных сложная древовидная структура.
podkolzzzin Автор
22.12.2021 16:26Ему тяжело, но он справляется(рекурсивные CTE)
На практике работал с такими данными, но обычно они обрабатывались до +/- реляционных до попадения в базу.
FanatPHP
22.12.2021 17:12+1Можно пример?
В тех проектах, с которыми работал я, небольшое подмножество ненормализуемых данных можно держать в поле типа json в нормальной БД и искать через эластик.
cross_join
22.12.2021 19:22Иерархические структуры встречается часто, SQL успешно с ними справляется, если правильно подойти к проектированию.
amarao
Идея интересная, хотя я SQL (язык, а не ACID-базы) очень не люблю за свою топорность уровня BASIC'а. Очень много слов, очень подробно там, где не нужно, и чем-то напоминает ассемблер.
Насколько я понимаю, гугловая logica как раз эту задачу и пытается решать.
podkolzzzin Автор
Местами он многословен, согласен
GooG2e
У меня лично одна придирка к SQL и больше связана даже с различными IDE к нему - сначала пишется что извлекается, а потом откуда. И всякие автоподборы сразу становятся тяжеле, потому что шерстится вся база.
podkolzzzin Автор
Раньше работал в компании, что строили IDE для SQL, как раз в команде code completion.
Мы там прошли через ад, что бы это подсказывать нормально(писал об этом в блоке Парсинг SQL и диалектов). В целом чаще, как мы выяснили набирают 'SELECT FROM tbl', а потом возвращаются в select list и указывают колонку. Когда сначала ставят * легче, потому что скрипт получается валидный, когда нет, все похуже.
Но в целом притензия здравая.