Змоделювала морський домен — фахівців, компанії, судна, вакансії, відгуки та решту — у 348 нормалізованих таблицях у межах 34 схем PostgreSQL, з довідниками SMALLINT та ключами UUID v7.

Ситуація. Серцем платформи є щільний морський домен — фахівці, компанії, судна, вакансії, відгуки, — і всі ці сутності постійно посилаються одна на одну. Фахівець ходить у рейси на суднах, працює в компаніях, залишає відгуки; компанія володіє суднами й публікує вакансії. Майже кожна функція — це запит через усю цю мережу зв’язків, тож від того, наскільки добре змодельовані дані, залежить, наскільки добре працює більшість застосунку і наскільки розумно його розширювати.

Завдання. Цей домен потрібно було змоделювати так, щоб він лишався швидким і зберігав цілісність, а додавання наступного типу сутності не перетворювалося на боротьбу зі схемою.

Дія. Дані організовано як нормалізовані схеми PostgreSQL, згруповані за доменами, — 348 таблиць у 34 схемах на цей момент. Численні дрібні стабільні переліки — статуси, типи, категорії — перетворено на довідкові таблиці SMALLINT, що робить рядки компактними, а джойни дешевими, замість того щоб зберігати текстові коди всюди. Сутності отримують первинні ключі UUID v7, тож вони глобально унікальні, але водночас часово впорядковані в індексі. Крізь усе проходить одна угода про іменування — таблиці в множині всередині схем з іменами в однині, — застосована без винятків, що як бонус дає змогу уникнути багатьох конфліктів із зарезервованими словами. А зв’язки підтримуються реальними foreign key та constraints, тож цілісність — це робота бази даних, а не те, що застосунок мусить пам’ятати сам.

Результат. Результатом стала модель даних, яка є послідовною і швидкою, а працювати з нею передбачувано, бо ті самі правила діють усюди — немає особливих випадків, які треба запам’ятовувати. Додавання функції зазвичай означає розширення схеми за наявною логікою, а не боротьбу проти неї, і це єдина причина, чому 34 схеми — це структура, а не розповзання. Це той фундамент, на якому стоїть решта платформи.