Я відносно свіжий поза коледжем, тому більшість мого знайомства з реляційними базами даних є з мого курсу баз даних, де все, що не є в BCNF або 3NF, є травестією. Безумовно, це один кінець крайності, але моя команда на роботі справді, здається, доводить це до протилежного кінця.
У наших схемах db для мікросервісів суб’єкти рідко мають більше однієї таблиці. Все, що ви зазвичай нормалізуєте в іншій таблиці, зберігається у колонці json. Якщо згодом буде виявлено, що один із властивостей цього json потрібно запитувати, додається новий стовпець і дані зберігаються в обох місцях (так, у двох різних стовпцях тієї ж таблиці).
У багатьох випадках ці json стовпці безумовно мають перевагу. Якщо вам ніколи не потрібно запитувати ці дані, і якщо вам ніколи не доведеться вносити односторонні зміни до цих даних (це очевидно, що ви, очевидно, не можете передбачити), це не погана ідея. Крім того, багато наших сервісів або не бачать сервер, або розміщуються на машинах з нецензурною кількістю дискового простору для того, що їм потрібно, тому дублювання даних не є великою проблемою. (Хоча я взагалі хотів би уникати філософії)
В даний час ми будуємо службу, яка відповідає правилам на основі набору належних їм умов, а потім виконує набір дій, пов’язаних із цими правилами, коли правила є істинними (наприклад, усі умови є істинними). Моя підкоманда, яка найчастіше будує цю службу, вважає, що для нормалізації дій та умов від норм у схемі є значна користь. Очевидно, що ця таблиця підтримує зовнішні ключові зв'язки з ідентифікатором правила. З нашого погляду ми можемо уникнути дублювання даних за умов, що дозволяють нам переконатися, що вони оцінюються лише один раз, і легко знайти необхідні умови та правила, коли вони знадобляться, не потрібно витягувати кожне правило і виконувати пошук у пам'яті.
Сьогодні, розмовляючи з одним із наших головних інженерів, він намагався відштовхнути мене від цієї схеми. Намагаючись всіляко стверджувати, що нам насправді це не потрібно, це спричинить проблеми в майбутньому, посилаючись на старий моноліт, який ми маємо, - це дизайнерська травестія. Він назвав те, що ми робимо як "по-старому", а плоскі столи з json як "новий шлях". Він стверджував, що там, де я хочу атомності, вона нам не потрібна і що замість запитів нам слід робити більше пам’яті. Це принцип дизайну, якого зараз дотримуються багато наших служб. Ми не передбачаємо, що обсяг наших даних істотно зросте, що повинно швидше підтримувати наші запити. Ми передбачаємо, що багато часу витрачається на оцінку правил та виконання дій.
Я розумію, що нереляційні бази даних стали більш популярними в останні роки, але навіть під час активного пошуку інформації про наслідки зовнішньополітичних ключових зв'язків я не бачу багато інформації, що робить його справою. Я гадаю, що вони, як правило, можуть вводити великі транзакції, які можуть спричинити проблеми, але це здається проблемою, незалежною від самого закордонного ключа.
Це моя наївність? Або це справді щось, чого я і моя підгрупа відсутні? Я чітко не дав детальної інформації щодо нашої проблеми, тому що я не обов'язково шукаю рішення для цього. Враховуючи, що це загальна тенденція в нашій більшій команді, мені дуже цікаво, якщо вони щось з цим вирішують.