NoSQL vs RDBMS: Too may FOREIGN KEYs
Oct. 24th, 2010 06:39 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclassСижу делаю очередную опердень, и наткнулся на печаль: таблицы содержат сильно больше внешних ключей и вообще структуры/связей (которые в FB основаны на индексах), чем собственно данных. Это после адекватной нормализации и отображения требуемой для расчетов структуры на базу данных. Типа того, что в таблице, где хранятся суммы, 4 поля, из них 3 - это разного рода ссылки на сущности "налогооблагаемый объект", "период расчета", "период уплаты", и одно поле - собственно сумма.
Причем раньше у меня было чисто технологическое ограничение - чем больше таблиц, тем больше приходилось писать вручную sql-скриптов, маппингов "таблицы-объекты", запросов для работы с таблицами. Я поэтому особо не нормализовал, шел по пути типа "нужно 12 месяцев - заводим 12 полей, нужно 4 квартала - заводим 4 поля". А сейчас, во первых, с кодогенератором это ограничение исчезло, а во вторых, 4 квартала и 12 месяцев превратились в "список периодов, диктуемый каждый отчетный год министерству по налогам и сборам Червем из астрального мира".
Т.е. если мы идем по пути "много структур данных и мало кода", который нам в голову диктует функциональщина, то отражение этого дела в RDBMS превращает ее в невероятно запутанный граф, в котором связи занимают больше места чем данные. Если бы это был NoSQL, а наши данные имели явно заметную тенденцию объединятся в объекты (т.е. работа с записями из связанных таблиц ведется всегда вместе), то мы бы просто ложили в NoSQL объект в виде xml/json/любой структурированный текст.
Бинарное представление в NoSQL было бы сильно эффективнее текста в плане размера и обработки, но, во первых для него нужна статическая типизация, схема и тому подобное (чтобы сериализация/десериализация были эффективными), и обработку этого должна делать СУБД, т.к. я совершенно не испытываю желания это все делать.
Кроме того, как уже неоднократно писалось: RDBMS работает эффективнее, т.к. ее данные, условно говоря - это последовательность бинарных записей одинаковой длины, хождение по которым - это +-длина записей. А всякая бинарщина и xml - это парсеры, сериализация и прочий плохо взаимодействующий с кэшами процессоров и выделением памяти тупизм.
В моем случае это все не применимо в принципе - 99% требуемой от разрабатываемого модуля функциональности уже реализовано в виде "Firebird+Универсальный толстый клиент на дельфи", основная обработка ведется SQL запросами и кодом внутри FB. Всунуться сюда с чем-то, хоть отдаленно похожим на NoSQL, невозможно. Т.е. постулат: NoSQL == разработка с нуля, что на данный момент неприемлемо никак.
Но вообще, даже если мы вместо чистого NoSQL придумаем какой-то хитрожопый вариант типа "статически типизированные объекты в бинарном виде", индексы по внутренностям этих объектов для оптимизации запросов, функциональщину в качестве языка запросов, то все равно останется проблема с тем, что объекты теперь не представимы в виде записей постоянной длины (хотя сейчас больше проблема с дисковым i/o, чем с нагрузкой на проц) и что все равно как-то придется идентифицировать объекты независимо от их физического расположения - а это означает опять ID, опять индексы, сопоставляющие ID и физическое расположение, опять связи по этим ID и прочая и прочая.
Причем раньше у меня было чисто технологическое ограничение - чем больше таблиц, тем больше приходилось писать вручную sql-скриптов, маппингов "таблицы-объекты", запросов для работы с таблицами. Я поэтому особо не нормализовал, шел по пути типа "нужно 12 месяцев - заводим 12 полей, нужно 4 квартала - заводим 4 поля". А сейчас, во первых, с кодогенератором это ограничение исчезло, а во вторых, 4 квартала и 12 месяцев превратились в "список периодов, диктуемый каждый отчетный год министерству по налогам и сборам Червем из астрального мира".
Т.е. если мы идем по пути "много структур данных и мало кода", который нам в голову диктует функциональщина, то отражение этого дела в RDBMS превращает ее в невероятно запутанный граф, в котором связи занимают больше места чем данные. Если бы это был NoSQL, а наши данные имели явно заметную тенденцию объединятся в объекты (т.е. работа с записями из связанных таблиц ведется всегда вместе), то мы бы просто ложили в NoSQL объект в виде xml/json/любой структурированный текст.
Бинарное представление в NoSQL было бы сильно эффективнее текста в плане размера и обработки, но, во первых для него нужна статическая типизация, схема и тому подобное (чтобы сериализация/десериализация были эффективными), и обработку этого должна делать СУБД, т.к. я совершенно не испытываю желания это все делать.
Кроме того, как уже неоднократно писалось: RDBMS работает эффективнее, т.к. ее данные, условно говоря - это последовательность бинарных записей одинаковой длины, хождение по которым - это +-длина записей. А всякая бинарщина и xml - это парсеры, сериализация и прочий плохо взаимодействующий с кэшами процессоров и выделением памяти тупизм.
В моем случае это все не применимо в принципе - 99% требуемой от разрабатываемого модуля функциональности уже реализовано в виде "Firebird+Универсальный толстый клиент на дельфи", основная обработка ведется SQL запросами и кодом внутри FB. Всунуться сюда с чем-то, хоть отдаленно похожим на NoSQL, невозможно. Т.е. постулат: NoSQL == разработка с нуля, что на данный момент неприемлемо никак.
Но вообще, даже если мы вместо чистого NoSQL придумаем какой-то хитрожопый вариант типа "статически типизированные объекты в бинарном виде", индексы по внутренностям этих объектов для оптимизации запросов, функциональщину в качестве языка запросов, то все равно останется проблема с тем, что объекты теперь не представимы в виде записей постоянной длины (хотя сейчас больше проблема с дисковым i/o, чем с нагрузкой на проц) и что все равно как-то придется идентифицировать объекты независимо от их физического расположения - а это означает опять ID, опять индексы, сопоставляющие ID и физическое расположение, опять связи по этим ID и прочая и прочая.
