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

=== 1. Безбедност на ниво на база
Имплементирани се следните безбедносни механизми директно при комуникацијата со базата, со што се намалува нападниот вектор независно од самиот NextJS сервер:
 - '''Заштита од SQL вбризгување(SQL injection):''' Клиентската библиотека `postgres.js` користи параметризирани прашалници преку Tagged Template Literals(на пример `sql\`...\``) по дизајн. Ова спречува директно извршување на малициозен SQL код преку корисничките влезни параметри, бидејќи влезот е секогаш парсиран како податок, а не како команда.
 - '''Енкриптирана комуникација(SSL/TLS):''' Како што е наведено во конфигурацискиот фајл([source:/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`) кои се компатибилно пресликани и преку типовите во [source:/app/lib/definitions.ts]:
{{{#!sql
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;
}}}

{{{#!sql
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;
}}}

{{{#!sql
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;
}}}

{{{#!sql
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 сервер обезбеден од надворешна инфраструктура. Конфигурацијата на серверот, резервните копии и механизмите за обновување на податоците се надвор од опсегот на самата апликација и зависат од околината во која е поставена базата на податоци.