Комментарии 18
Делайте хорошо и не делайте плохо
Чем плоха таблица с col1487 находящаяся во второй нф? Например есть котельная и в ней 5000 приборов и часть метрик принадлежат одной группе, и сохраняются в одну таблицу.
Для рефакторинга и сопровождения (называется оптимизация и нормализация бд) я бы посоветовал иметь в наличии тестовые скрипты, которые помогут протестировать любой форк базы и показать 95% процентиль, время отклика, и прочие метрики бд.
широкая таблица
Приведенные примеры, это не широкая таблица, а денормализация. И есть случаи, когда денормализация, например, в виде использования массивов, оправдана, так как дает существенный прирост производительности.
Общее количество полей в таблице существенного значения не имеет. Горизонтальное разделение таблицы на две с отношением один-к-одному имеет смысл только в редких сценариях, когда часть полей в запросах используется на 2 и более порядка реже, чем другая часть.
лучше использовать третью нормальную форму
Лучше стремиться к максимально нормализованной БД, но до тех пор, пока это не приводит к деградации производительности. А без нарушений третей нормальной формы, например, для хранения агрегатов, обойтись очень сложно.
минимизировать использование вызовы функций в условиях WHERE
Надо не столько минимизировать их использование, сколько следить за тем, чтобы результат функции был применим для поиска по индексу.
При написании SQL запросов, особое внимание стоит обращать на количество логических чтений
План запроса надо смотреть в первую очередь, а не количество логических чтений.
не рекомендуется использовать такой механизм баз данных как хранимые процедуры
Очень сильно зависит от задач. В общем случае, вообще без триггеров, которые являются видом хранимых процедур, в БД не обойтись.
С некоторыми операциями базы данных справляются достаточно плохо
Лучше решать эти проблемы функциями. На PostgreSQL, после C, наилучший результат дает Rust, хотя Java или Python часто тоже достаточно. На MS SQL - С#.
Если полностью раскрывать все вопросы, то это уже целая книга будет :) На это я пойти не готов (пока).
Contragents, Cols: Addr1, Addr2, Phone, MobilePhone - ну это уж точно широкая таблица.
По поводу широких таблиц думаю в считанных приложения это оправдывает себя, просто просчет вполне дешевой альтернативы в виде нормальной формы обычно не делается для большинства приложений.
Contragents, Cols: Addr1, Addr2, Phone, MobilePhone - ну это уж точно широкая таблица.
Это все же денормализация. Причем совершенно не оправданная. У клиента может быть больше двух адресов и телефонов. А вот для колесной пары указывать толщину реборд в одной записи уже логично, так как этих реборд там всегда две и они конструктивно представляют собой единое целое.
Ширина таблицы - это количество полей в ней, а не их семантика.
В дополнение к пункту 3.
Настоятельно рекомендую использовать одинаковые имена для референсных полей в обеих таблицах. В остальном - использовать имена полей (или пар полей для референсных), уникальные в рамках базы данных. NATURAL JOIN и JOIN USING - весьма удобные и логичные конструкции.
Также рекомендую формировать имена вложенных объектов (констрейнты, индексы, триггеры и пр.) таким образом, чтобы они однозначно определяли базовый объект. Следствие - формировать эти имена явно, а не полагаться на автоматически создаваемые, когда это возможно.
По пункту 6.
Использованный термин SARGable (пишется именно так) надо было описывать в пункте 5. А сам пункт 6 после этого - вообще выбросить.
По пункту 9.
Это в основном болезнь (причём хроническая) всех фреймворков - либо в них вообще отсутствует поддержка хранимых объектов, либо она куцая и выполнена через универсальный интерфейс. И если на отсутствие поддержки ХП ещё можно наплевать и забыть, то вот то же для триггеров - это пичалька.
По пункту 17.
Вы свалили в одну кучу набор БД в рамках одного инстанса СУБД, и набор инстансов СУБД.
По пункту 21.
Применимость зависит от того, как СУБД обрабатывает CTE. Например, старые версии Постгресса однозначно материализуют результат CTE... А потому совет запросто может оказаться вредным.
По пункту 23.
Вообще неясно, о чём именно речь. Не используйте TEXT, если нужно хранить CHAR(1), что ли?
По пункту 24.
О чём речь? партиционирование? горизонтальный шардинг? вертикальный? что-то ещё?
...
Для чего настраивать и тестировать механизмы бекапов?
Чтобы не потерять данные :) Подробнее можно почитать в данной статье https://habr.com/ru/companies/dataline/articles/329046/
Рекомендации по разработке баз данных и клиентских приложений