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

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

Започнете со прашањата што ги поставува вашата апликација

Дизајнот на шемата често започнува со именки: корисници, нарачки, производи, фактури. Тоа е корисно, но нецелосно. Перформансите во голема мера зависат од глаголите: пронајдете ги неодамнешните нарачки на клиентот, резервирајте залихи, наведете ги неплатените фактури, пресметајте вкупен износ за контролна табла, преземете API-ресурс со неговите врски.

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

На пример, листата на нарачки најчесто може да има потреба од нарачките за еден клиент, најновите први:

SELECT id, status, total_amount, created_at
FROM orders
WHERE customer_id = ?
ORDER BY created_at DESC
LIMIT 50;

Композитен индекс што започнува со customer_id и продолжува со created_at е усогласен со тоа барање:

CREATE INDEX orders_customer_created_at_idx
ON orders (customer_id, created_at DESC);

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

Моделирајте ја вистината пред да ја оптимизирате практичноста

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

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

CREATE TABLE order_items (
    id BIGINT PRIMARY KEY,
    order_id BIGINT NOT NULL,
    product_id BIGINT NOT NULL,
    quantity INTEGER NOT NULL,
    unit_price DECIMAL(12, 2) NOT NULL,
    FOREIGN KEY (order_id) REFERENCES orders(id),
    FOREIGN KEY (product_id) REFERENCES products(id)
);

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

Нормализирајте стандардно, денормализирајте со докази

Нормализацијата ги намалува дуплирањето и аномалиите при ажурирање. Таа обично е правилната почетна точка за трансакциски системи бидејќи на секој факт му дава едно авторитативно место. Е-поштата на клиентот припаѓа кај клиентот; деталите за производот припаѓаат кај производот; ставката од нарачката ги опфаќа фактите специфични за тоа купување.

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

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

Изберете типови на податоци што го одразуваат доменот

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

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

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

CREATE TABLE team_members (
    team_id BIGINT NOT NULL,
    user_id BIGINT NOT NULL,
    role VARCHAR(50) NOT NULL,
    PRIMARY KEY (team_id, user_id),
    FOREIGN KEY (team_id) REFERENCES teams(id),
    FOREIGN KEY (user_id) REFERENCES users(id)
);

Овој дизајн природно спречува дуплирано членство и поддржува барање на членовите на тимот преку примарниот клуч.

Дизајнирајте индекси според реалните облици на барања

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

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

Бидете особено внимателни со флексибилните филтри за пребарување. Една крајна точка „наведи сè“ со опционални филтри може да доведе до шума од индекси, а сепак да создава лоши планови. Често подобар одговор е да се дефинираат неколку поддржани обрасци на барања, доследно да се пагинира и на специјализираните извештаи да им се даде сопствена намерно осмислена патека за податоци.

Задржете ги API-јата и миграциите во разговорот за дизајнот

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

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

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

Направете ја одржливоста карактеристика на перформансите

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

Перформансите се својство на системот. Разумна шема, насочени индекси, предвидливи API-барања и внимателни распоредувања меѓусебно се зајакнуваат. Започнете со вистината на доменот, оптимизирајте ги патеките што корисниците навистина ги користат и барајте докази пред да додадете сложеност. Тоа е прагматичниот пат: не совршена шема замрзната во времето, туку јасен модел што може да еволуира без да стане тесното грло што требало да го спречи.