Останати теми: Безбедност, перформанси и одржување на базата

1. Безбедност на ниво на база

Имплементирани се следните безбедносни механизми директно при комуникацијата со базата, со што се намалува нападниот вектор независно од самиот NextJS сервер:

• Заштита од SQL вбризгување(SQL injection): Клиентската библиотека postgres.js користи параметризирани прашалници преку Tagged Template Literals(на пример sql\...\) по дизајн. Ова спречува директно извршување на малициозен SQL код преку корисничките влезни параметри, бидејќи влезот е секогаш парсиран како податок, а не како команда.
• Енкриптирана комуникација(SSL/TLS): Како што е наведено во конфигурацискиот фајл(app/lib/db.ts#L11​), конекцијата кон базата строго наметнува SSL сертификат преку параметарот ssl: 'require'. Ова ја штити транзицијата на чувствителните податоци и лозинки од "man-in-the-middle" напади.
• Безбедно поврзување со база: Конекциските стрингови никогаш не се чуваат во изворниот код. Тие се изолирани преку заштитени околински променливи (POSTGRES_URL).

2. Перформанси и оптимизација

• Стратегија на индексирање: Базата користи B-Tree индекси кои PostgreSQL автоматски ги креира за примарните клучеви(PRIMARY KEY) и уникатните ограничувања(UNIQUE). На тој начин е овозможен брз пристап до записите при пребарување по идентификатори на ентитетите, како и при проверка на единственоста на корисничките е-пошти. Индексите моментално постојат над колоните user.user_id, user.email, transaction.transaction_id, transaction_account.transaction_account_id, transaction_breakdown.transaction_breakdown_id, tag.tag_id и tag_assigned_to_transaction.tag_assigned_to_transaction_id.
• Оптимизација преку релациски ограничувања: Сите врски помеѓу табелите се реализирани преку надворешни клучеви(FOREIGN KEY), со што PostgreSQL може ефикасно да го одржува интегритетот на податоците при вметнување, ажурирање и бришење на записи.
• Подготвеност за понатамошна оптимизација: Со растот на количината на податоци, можно е дополнително индексирање на колони кои често се користат при филтрирање и поврзување на податоците, како што се transaction.date, transaction_account.user_id, transaction_breakdown.transaction_id и tag_assigned_to_transaction.transaction_id. Ваквата оптимизација е особено корисна кај статистичките извештаи и аналитичките прашалници кои обработуваат поголем број трансакции.

3. Интегритет и конзистентност

Со цел самата база да биде отпорна на грешки, имплементирани се стриктни ограничувања (CONSTRAINTS) кои се компатибилно пресликани и преку типовите во app/lib/definitions.ts​:

ALTER TABLE transaction_account
DROP CONSTRAINT transaction_account_user_id_fkey;

ALTER TABLE transaction_account
ADD CONSTRAINT transaction_account_user_id_fkey
FOREIGN KEY (user_id)
REFERENCES "user"(user_id)
ON DELETE CASCADE;

ALTER TABLE transaction_breakdown
DROP CONSTRAINT transaction_breakdown_transaction_id_fkey;

ALTER TABLE transaction_breakdown
ADD CONSTRAINT transaction_breakdown_transaction_id_fkey
FOREIGN KEY (transaction_id)
REFERENCES "transaction"(transaction_id)
ON DELETE CASCADE;

ALTER TABLE transaction_breakdown
DROP CONSTRAINT transaction_breakdown_transaction_account_id_fkey;

ALTER TABLE transaction_breakdown
ADD CONSTRAINT transaction_breakdown_transaction_account_id_fkey
FOREIGN KEY (transaction_account_id)
REFERENCES transaction_account(transaction_account_id)
ON DELETE CASCADE;

ALTER TABLE "user"
ADD CONSTRAINT user_email_unique UNIQUE (email);

• Надворешни клучеви и каскадно бришење: Сите релации помеѓу ентитетите се заштитени со надворешни клучеви(FOREIGN KEY). За зависните записи е конфигурирано каскадно бришење(ON DELETE CASCADE), со што се спречува појава на невалидни или неповрзани податоци. При бришење на корисник автоматски се отстрануваат неговите сметки и поврзаните записи за распределба на трансакции. На ист начин, при бришење на трансакција или таг, автоматски се бришат и зависните записи кои се поврзани со нив.
• Ограничувања на уникатност: Корисничките мејлови се заштитени со UNIQUE ограничување, со што се гарантира дека во системот не можат да постојат два кориснички профили со иста емаил адреса.
• Типови на податоци за финансиски вредности: Сите монетарни вредности во системот се складираат со типот NUMERIC(10,2). Овој пристап обезбедува фиксна прецизност до две децимали и ги елиминира грешките кои можат да настанат при користење на типови со подвижна запирка(FLOAT или DOUBLE PRECISION) во финансиски пресметки.

4. Одржување на базата

• Зачувување на структурните промени: Секоја промена на структурата на базата се документира во Trac документацијата и се имплементира директно во PostgreSQL преку SQL наредби. На тој начин документацијата останува усогласена со реалната имплементација на системот.
• Чување на SQL скриптите: Секоја SQL скрипта извршена после првата DDL скрипта ја чувам хронолошки, за во случај да треба базата да се иницијализира повторно, да ги извршам редоследно и да ја добијам истата состојба која сум ја имал.
• Одговорност за инфраструктурата: FEiN е дизајниран да работи врз PostgreSQL сервер обезбеден од надворешна инфраструктура. Конфигурацијата на серверот, резервните копии и механизмите за обновување на податоците се надвор од опсегот на самата апликација и зависат од околината во која е поставена базата на податоци.