Комментарии 24
Идея хорошая, но, судя по "примерам", матчасть нужно подтянуть)))
матчасть
Какие преимущества по сравнению с обычными RDBMS и использованием нормального SQL? Я так понимаю все равно под капотом там реляцоинная БД?
В чем смысл атрибуты нумеровать, а не использовать строки как идентификаторы, хотя бы для улучшения читабельности?
Да. Под капотом там действительно RDBMS Oracle 11g. И, естественно, это не графовая БД. ИБД это заголовок статьи, а по сути это иерархическая модель данных, реализованная на RDBMS. Внутренний язык запросов и отражает эту сущность. Во второй части, которую я выложу на днях, я и показываю, насколько легче пользоваться AQL по сравнению с SQL. То что на AQL пишется в 3 строчки, на SQL потребует 30. И разрабатывалась такая структура для существенного снижения требования к разработчикам. Разработчику вообще не требуется быть специалистом в БД и SQL.
Так почему было не взять графовую субд и получить те же самые запросы в 3 строчки?
Прочитал всё... но так и не понял, что вообще заставило использовать подход иерархической БД (ИБД), когда снизу - реляционная СУБД, на которой ИБД реализуется легко и непринуждённо, считай нативно, достаточно всего лишь некоторого самоограничения. Ну и терминология - что бы не использовать стандартную и уже устоявшуюся?
Отношение М:М между двумя сущностями легко реализуется через нижний узел (абcтрактную сущность).
Ну то есть просто превращаем иерархическую БД в реляционную, что ли? Ну или не превращаем, да, маловато будет, но используем технологию из реляционной БД. Просто с точки зрения иерархической БД такая промежуточная сущность безусловно является самостоятельной сущностью, возможно, не имеющей атрибутов, тогда как в реляционной БД считать такую промежуточную таблицу сущностью никто не заставляет (хотя и не запрещает - и порой считают). Но это всего лишь вопрос терминологии. Или глубины анализа предметной области.
реляционная СУБД, на которой ИБД реализуется легко и непринуждённо, считай нативно, достаточно всего лишь некоторого самоограничения
Это как?
А что есть такого в ИБД, что отсутствует в РСУБД? Я что-то навскидку и не нахожу... а, значит, ИБД - это РСУБД с дополнительными ограничениями.
Упорядоченность, например. Или прямые ссылки между узлами, позволяющие выбирать поддеревья без лукапа.
Упорядоченность
А теперь точно и подробно, что именно имеется в виду. Хранимая таблица - это несортированная и неупорядоченная куча, причём так дело обстоит в обеих СБД. Что именно упорядочено? где? как?
прямые ссылки между узлами, позволяющие выбирать поддеревья без лукапа
Да ладно! Вот так прям в каждой записи каждой таблицы и лежит полный путь текущей записи, перечисляющий узлы во всех таблицах аж до самого корня дерева связей? Вот что-то не верится.
не понял, что вообще заставило использовать подход иерархической БД (ИБД)
Это именно тот случай, когда правильно поставленный вопрос сам содержит в себе ответ.
Сложно понять в деталях. Задам вопросы.
В вашем инструменте, каким образом реализован:
1. DDL - модификация схемы бд, согласно метаданным (в окошках скриншотов)?
2. UI - виндовый / веб?
3. Сервисы (фоново-работающие процессы)?
4. Логика валидации данных на UI?
5. Логика валидации данных SQL?
6. Есть ли возможность создавать микросервисы из вашей универсальной среды, или это исключительно описание модели предприятия?
7. Версионирование всех ваших метаданных
8. Перенос изменений из среды разработки в среды тестирования, прод и DR?
Во вторник-среду выложу вторую часть. Там на большинство вопросов будут ответы.
Модификации схемы БД не требуется. Разработчик ее вообще не видит.
UI - виндовый.
Валидация данных происходит на сервере приложений (в самом начале написано, система трехзвенная СУБД - сервер приложений (Windows или Linus) - тонкий клиент под Windows).
Система поддержания версионности и совместной разработки встроенная. Разработчик "берет на редактирование" процедуру или экранную форму, изменяет и "отдает в использование". Пока не "отдал", для всех пользователей "видна" старая версия. Версии можно откатить.
Отдельных сред разработки и тестирования нет. Есть единая система, в которой пользователь с правами разработчика может для любой экранной формы вызвать редактор, "забрать форму на редактирование", изменить, работать с ней, тестировать и т.д.. И после "отдачи" она становиться "видимой" для всех.
И главное - система разрабатывалась где-то с 1994 года. Практически законченный вид она приобрела в 2000-2001. Тогда еще "устоявшейся" терминологии не было. Ни GIT, ни SVN, ни Postgres, ничего этого еще не было. Даже SQL сервер и близко не мог того, что мог Oracle.
Зашел прояснить свои вопросы, увидел "минус" на свой предыдущий коммент и решил что "нунафиг". Лучше буду только читать. :)
Было бы здорово провести исследование, почему подобные мышко-прикладные системы, где разработчик по сути и не разработчик, а интегратор, не поглотили всю индустрию целиком. Абстракции над БД, создающие свой специфический язык к данным, высокоуровневые бизнес-концепции "сущность", "связь", "подчинённость", не наблюдаю пока повального погребения устаревшего SQL, и построения систем на низкоуровневых фреймворках. Как думаете, с чем это связано, не логично же?
select
#.2,
#.7,
#.187,
#:2015 range2_val(#.1,#.52,%CP).25,
#:2015 range2_val(#.1,#.52,%CP)^205.184,...
Обалденно.
Поздравляю, вы почти изобрели EAV
Иерархическая база данных