Функциите со вештачка интелигенција ретко откажуваат затоа што моделот не може да прочита табела. Тие откажуваат затоа што базата на податоци раскажува нецелосна приказна. Колона наречена status може да биде совршено разбирлива за тимот што ја изградил, но двосмислена за помошник, процес на пребарување, аналитички агент или следниот развивач што го одржува системот.

Усовршувањето на шемата за подлабоко разбирање од ВИ не значи секоја табела да се направи „подготвена за ВИ“ со нов префикс или векторска колона. Станува збор за тоа деловното значење да биде експлицитно, односите сигурни, а оперативните правила лесно откриливи. Овие промени исто така го подобруваат обичниот апликациски код, API-јата, известувањето, миграциите и одговорот на инциденти.

Направете го јазикот на доменот видлив

Шемите на бази на податоци акумулираат скратеници. Табела наречена txn може да претставува фактура, обид за плаќање, ставка во главната книга или сите три. Поле наречено type може да значи тип на документ, метод на испорака, категорија на сметка или настан од животниот циклус. Луѓето со текот на времето го учат овој контекст од тикети и прегледи на код. Автоматизираните системи ја немаат таа привилегија.

Користете имиња што го изразуваат концептот на доменот и неговиот опсег. Претпочитајте payment_attempt наместо transaction кога редот претставува обид за наплата на пари. Претпочитајте subscription_state наместо status кога вредноста припаѓа конкретно на животниот циклус на претплата.

Ова не е аргумент за претерано долги имиња. Тоа е аргумент за отстранување на двосмисленоста на границите каде што софтверот треба да расудува за податоците. Јасните имиња ја намалуваат можноста систем со ВИ да поврзе погрешни ентитети, да генерира погрешно насочено барање или да претстави самоуверено, но неточно објаснување.

Одделете ги концептите што се менуваат од различни причини

Чест извор на забуна е табела што комбинира неколку поврзани, но независни концепти. Разгледајте запис за нарачка во кој состојбата на плаќањето, исполнувањето и корисничката поддршка се компресирани во една вредност status. Може да функционира на почетокот, но станува тешко да се одговори на едноставно прашање како: „Кои платени нарачки чекаат испорака?“

CREATE TABLE orders (
    id BIGINT PRIMARY KEY,
    customer_id BIGINT NOT NULL,
    payment_status VARCHAR(32) NOT NULL,
    fulfillment_status VARCHAR(32) NOT NULL,
    support_status VARCHAR(32) NOT NULL,
    created_at TIMESTAMP NOT NULL
);

Одделните полиња не ја елиминираат деловната сложеност, но ја прават видлива. Агент со ВИ сега може да ја идентификува релевантната димензија на состојбата, наместо да нагаѓа што значи status = 'pending'. Вашите API-ракувачи и барања за известување имаат корист од истата прецизност.

Моделирајте ги односите како факти, а не како конвенции

Односите се местото каде што значењето на шемата станува оперативно. Ако односот постои само во апликацискиот код, секој потрошувач надолу по текот мора повторно да го открие. Странските клучеви, конзистентните имиња на клучеви и соодветните ограничувања ѝ даваат на базата на податоци сигурен опис за тоа како се поврзуваат ентитетите.

На пример, invoice.customer_id е полесно да се толкува од генеричко owner_id. Ако полиморфизмот е неопходен, направете го неговиот тип експлицитен со полиња како subject_type и subject_id, а потоа документирајте ги валидните типови близу до дефиницијата на моделот или шемата. Избегнувајте полиморфни асоцијации кога обичните релациони табели попрецизно го опишуваат доменот.

• Користете примарни клучеви конзистентно и именувајте ги странските клучеви според референцираниот ентитет.
• Наметнете ги односите со ограничувања на странски клучеви кога правилата за распоредување и задржување го дозволуваат тоа.
• Користете табели за поврзување за вистински односи многу-кон-многу, наместо идентификатори разделени со запирки.
• Чувајте временски ознаки со јасна семантика, како paid_at, cancelled_at и fulfilled_at.

Ограничувањата се особено вредни бидејќи разликуваат можност од инваријанта. Поле што може да биде null вели дека отсуството е дозволено. Ограничувањето за единственост вели дека дуплирањето не е. Ограничувањето за проверка може да изрази ограничен домен. Тоа се корисни сигнали и за луѓето и за системите што генерираат код или барања.

Изберете структурирани вредности пред фрагменти од природен јазик

Текстот со слободна форма има валидно место: белешки, пораки, описи и содржина доставена од корисници. Тој е лоша замена за полиња што управуваат со работни текови. Ако апликацијата треба да филтрира, агрегира, овластува, насочува или валидира вредност, дајте ѝ на таа вредност структурирано место.

Наместо да ги закопувате претпочитаните начини на испорака во белешка, моделирајте го избраниот метод. Наместо да кодирате приоритет во наслов, користете ограничено поле за приоритет. Наместо да го заклучувате животниот циклус на фактурата од историја на коментари во проза, евидентирајте ја релевантната состојба на животниот циклус и времињата на настаните.

Структурираните податоци ја подобруваат сигурноста на барањата и им даваат на системите со ВИ стабилни влезови. Природниот јазик потоа може да го збогати структурираниот запис, наместо сам да носи критично оперативно значење.

Не претворајте ја секоја вредност во enum

Прагматизмот е важен. Строго контролираната состојба на животниот циклус е добар кандидат за ограничена вредност слична на enum. Етикета што ја конфигурира корисникот не е. Претерано ригидните шеми ги прават промените на производот скапи и може да ги вратат тимовите кон неструктурирани излезни решенија.

Користете референтна табела кога на вредностите им се потребни метаподатоци, локализација, редослед, конфигурација специфична за закупец или управуван животен циклус. Користете едноставна ограничена низа или enum што е природен за базата на податоци кога вредностите се стабилни и процесот на распоредување може безбедно да ги развива. Важното е дека дозволеното значење е намерно и видливо.

Зачувајте го контекстот околу чувствителните и изведените податоци

Многу недоразбирања со ВИ доаѓаат од податоци што изгледаат авторитативно, но немаат потекло. Оценка, резиме, класификација или препорака не треба да се чува како необјаснета конечна вредност кога нејзиното потекло влијае врз одлуките.

Каде што е соодветно, задржете полиња што одговараат на практични прашања: Што ја произведе оваа вредност? Кога беше произведена? Која верзија на влезот беше користена? Дали беше прегледана или заменета? Ова не се само прашања поврзани со ВИ. Тие се суштински за дебагирање, проверливост и безбедно враќање назад кога деловната логика се менува.

CREATE TABLE document_classifications (
    id BIGINT PRIMARY KEY,
    document_id BIGINT NOT NULL,
    classification VARCHAR(64) NOT NULL,
    confidence DECIMAL(5,4),
    generated_at TIMESTAMP NOT NULL,
    reviewed_at TIMESTAMP NULL,
    reviewer_id BIGINT NULL,
    FOREIGN KEY (document_id) REFERENCES documents(id)
);

Шема како оваа го одржува генерираниот излез одделен од човечкиот преглед. Таа спречува потрошувач на API да третира автоматизирана класификација како одобрен деловен факт.

Дизајнирајте го речникот на базата на податоци и API-то заедно

Чистата шема не бара директно изложување на табелите преку API. Всушност, обично не треба. Но имињата во базата на податоци, имињата на API-ресурсите, носивоста на настаните и документацијата треба да го опишуваат истиот домен со компатибилни термини.

Ако базата на податоци нешто го нарекува payment_attempt, API-то не треба лежерно да го нарекува фактура, освен ако намерно претставува различна апстракција. Кога се неопходни различни термини, документирајте го преводот. Конзистентниот речник им олеснува на алатките за развој потпомогнати со ВИ да следат барање од крајна точка до услуга до слојот на перзистенција без да измислуваат концептуални врски.

Подобрувајте безбедно преку мали миграции

Усовршувањето на шемата е продукциска промена, а не вежба за чистење низ која треба да се помине набрзина. Преименувајте и преобликувајте ги податоците со период на компатибилност кога активни апликации, работници, интеграции или задачи за известување зависат од постојните колони.

1. Додадете го новото поле или табела без да ја отстраните старата структура.
2. Пополнете ги постојните податоци со експлицитна, проверлива миграција.
3. Ажурирајте ги запишувачите за да ја пополнуваат новата претстава.
4. Преместете ги читателите по проверката на пополнувањето и новите запишувања.
5. Отстранете ја старата структура само откако зависниот код и интеграциите повеќе не ја користат.

За големи табели, испланирајте групирање, индекси, однесување на заклучувањето и враќање назад пред распоредувањето. Семантички подоброто име на колона не вреди за прекин што може да се избегне. Третирајте ја логиката за миграција на податоци со истата дисциплина при преглед како апликацискиот код.

Јасноста е интерфејс

Системите со ВИ го засилуваат она што шемата го соопштува. Ако моделот е нејасен, неконзистентен или зависен од неформално знаење во тимот, автоматизацијата ќе ја засили и таа неизвесност. Ако моделот јасно изразува ентитети, состојби, односи и потекло, ВИ може да стане покорисен помошник наместо поефикасен извор на веродостојни грешки.

Трајната придобивка е поширока од ВИ. Добро усовршената шема е траен интерфејс помеѓу денешната апликација и инженерите од утре. Направете базата на податоци точно да го објаснува бизнисот, и секој слој изграден над неа има поголема шанса да го прави истото.