Об’єктно-орієнтований варіант вирішення
Однак рішення все ж є. На прикладі MySQL можна показати, як стандартні реляційні таблиці перетворюються в об’єктно-орієнтовану модель розв’язуваної задачі.
Тут немає бази даних, але є середовище для формування власної системи об’єктів. Потужності MySQL використовуються тільки як реляційна пам’ять для таблиць з інформаційних рядків. Логіку використання визначає сам розробник. Зокрема, є таблиця is_cache. У ній усього кілька основних полів:
- owner_code;
- session_code;
- h_code;
- a_surprise;
- a_contents.
Інші поля несуть в собі службові функції. Дана таблиця стоїть на вході будь-якого запиту і фіксує його надходження. Що відпрацює модель бази даних, визначає її розробник. Що поміститься в полі змісту (a_contents), визначають об’єкти моделі, створеної розробником.
У такої ідеї є чотири моменти: звернення, сесія звернення, код історії звернень і конкретний зміст. Що таке звернення, яка система об’єктів повинна бути побудована – визначає розробник. Що розуміти під сесією (процесом роботи) – визначає розробник. Код історії – це можливість відкату за зверненнями.
Таблиці тут не мають ніякого відношення до предметної області. Є контролер звернень (is_cache), є протоколювання (is_customs), є історія звернень (is_histories). Інші таблиці визначаються розв’язуваної завданням.
По суті, таке рішення пропонує створювати власну ООБД на базі побудованої моделі бази даних предметної області розв’язуваної задачі. Тут є величезний плюс – це власне поняття даних, власна модель їх подання та взаємозв’язків між ними. Тут є фундамент – відмінна реляційна база даних. Тут не буде проблем щось шукати і щось недопонимать.
