Changes between Version 1 and Version 2 of OtherTopics

Timestamp:

06/16/26 12:57:11 (4 days ago)

Author:

211101

Comment:

--

OtherTopics

@@ -1 +1 @@
 = Останати теми: Безбедност, перформанси и одржување на базата
 
-=== 1. Безбедност на ниво на база (Database Security)
+=== 1. Безбедност на ниво на база
 Имплементирани се следните безбедносни механизми директно при комуникацијата со базата, со што се намалува нападниот вектор независно од самиот NextJS сервер:
- - '''Заштита од SQL вбризгување(SQL Injection):''' Клиентската библиотека `postgres.js` користи параметризирани прашалници преку Tagged Template Literals(на пример `sql\`...\``) по дизајн. Ова спречува директно извршување на малициозен SQL код преку корисничките влезни параметри, бидејќи влезот е секогаш парсиран како податок, а не како команда.
+ - '''Заштита од 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 сервер обезбеден од надворешна инфраструктура. Конфигурацијата на серверот, резервните копии и механизмите за обновување на податоците се надвор од опсегот на самата апликација и зависат од околината во која е поставена базата на податоци.