За всички публични интернет страници трябва да бъде реализирана функционалност за публикуване на всяко периодично обновявано съдържание (новини, обявления);
Сайтът трябва да поддържа възможност за автоматично генериране на електронни бюлетини, които да се разпращат периодично или при настъпване на събития по електронна поща до регистрираните в сайта електронни адреси, с които е заявено желание да получават такива бюлетини.
Системен журнал
Изгражданото решение задължително трябва да осигурява проследимост на действията на всеки редактор (администратор на сайта), както и версия на предишното състояние на данните, които той е променил в резултат на своите действия.
Атрибутите, които трябва да се запазват при всеки запис, трябва да включват като минимум следните данни:
модул на системата, в който се извършва действието;
действие;
обект, над който е извършено действието;
допълнителна информация;
IP адрес и браузър на потребителя.
Размерът на журнала на потребителските действия нараства по време на работа на всяка система, което налага по-различното му третиране от гледна точка на организация на базата данни:
по време на работа на сайта потребителският журнал трябва да се записва в специализиран компонент, който поддържа много бързо добавяне на записи; този подход се налага, за да не се забавя излишно работата на сайта;
специална фонова задача трябва да акумулира записаните данни и да ги организира в отделна специално предвидена за целта база данни, отделна от работната база данни на системата;
данните в специализираната база данни трябва да се архивират и изчистват, като в специализираната база данни трябва да бъде достъпна информация за не повече от 2 месеца назад; при необходимост от информация за предишен период администраторът на сайта трябва първо да възстанови архивните данни;
трябва да бъде предоставен достъп до системния журнал на органите на реда чрез потребителски или програмен интерфейс; за достъпа трябва да се изисква електронна идентификация.
Дизайн на бази данни и взаимодействие с тях
При разработването на сайта следва да бъдат следвани добрите практики за дизайн. Дизайнът трябва да бъде съобразен с изискванията на Главния секретариат на Съвета на ЕС, както и на Министерството за Българското председателство на ЕС. Дизайнът трябва да бъде приложен след одобрението на Възложителя.
дизайнът на схемата на базата данни (ако има такава) трябва да бъде с максимално ниво на нормализация, освен ако това не би навредило сериозно на производителността;
базата данни трябва да може да оперира в клъстър; в определени случаи следва да бъде използван т.нар. sharding;
имената на таблиците и колоните трябва да следват унифицирана конвенция;
трябва да бъдат създадени индекси по определени колони, така че да се оптимизират най-често използваните заявки; създаването на индекс трябва да е мотивирано и подкрепено със замервания;
връзките между таблици трябва да са дефинирани чрез foreign key;
периодично трябва да бъде правен анализ на заявките, включително чрез EXPLAIN (при SQL бази данни), и да бъдат предприети мерки за оптимизиране на бавните такива;
задължително трябва да се използват транзакции, като нивото на изолация трябва да бъде мотивирано в предадената документация;
при операции върху много записи (batch) следва да се избягват дългопродължаващи транзакции;
заявките трябва да бъдат ограничени в броя записи, които връщат;
при използване на ORM или на друг слой на абстракция между приложението и базата данни, трябва да се минимизира броят на излишните заявки (т.нар. n+1 selects проблем);
при използване на нерелационна база данни трябва да се използват по-бързи и компактни протоколи за комуникация, ако такива са достъпни.