У моей компании есть модель развития, похожая на водопад, где наши бизнес-пользователи и бизнес-аналитики будут определять требования к проектам. В одном из наших «больших» проектов мы получили набор требований, и я заметил, что ряд требований содержал детали реализации , в частности информацию, касающуюся схемы нашей базы данных, используемой нашей системой учета.
Я прокомментировал бизнес-пользователям, что реализация - это мой домен, он не должен содержаться в требованиях. Они не хотели менять свои требования, потому что, в конце концов, они ДЕЛА, а для бухгалтеров имеет смысл разрабатывать бухгалтерские программы. Как скромный разработчик, который слишком далеко опущен в тотемный опрос, мне платят , а не думают . Как бы я ни боролся с этим, я не мог убедить их переписать требования - слишком много бумажной работы и волокиты вокруг изменений, что просто слишком хлопотно.
Итак, я дал им то, что они просили. По крайней мере, это работает , но база данных странно разработана:
Много ненужной нормализации. Одна запись, содержащая 5 или 10 полей, разбивается на 3 или 4 таблицы. Я могу с этим справиться, но лично я хотел бы, чтобы все поля 1: 1 были объединены в одну таблицу.
Много неуместной денормализации. У нас есть таблица, в которой хранятся данные счетов-фактур, в которых хранится больше данных о счетах. Мы храним несколько разных флагов в таблице InvoiceData, даже если флаг логически не связан с таблицей InvoiceData, так что каждый флаг имеет магическое, жестко заданное значение первичного ключа и все другие поля, обнуляемые в таблице InvoiceData. Поскольку флаг представлен в виде записи в таблице, я предложил перенести флаг в его собственную таблицу.
Много больше неуместной денормализации. Некоторые флаги всего приложения хранятся в виде столбцов в неподходящих таблицах, поэтому изменение флага приложения требует обновления каждой записи в таблице.
Первичные ключи содержат метаданные, например, если первичный ключ varchar оканчивается на «D», мы рассчитываем счета-фактуры, используя один набор значений, в противном случае мы рассчитываем его с другим набором. Было бы разумнее перенести эти метаданные в отдельный столбец или перетащить набор значений для расчета в другую таблицу.
Внешние ключи часто идут в более чем одну таблицу, так что внешний ключ, заканчивающийся на «M», может ссылаться на нашу таблицу учетных записей, в то время как внешний ключ, заканчивающийся на «A», может ссылаться на нашу таблицу автоматических учетных записей. Было бы проще разделить данные на две таблицы, MortageData и AutoInsuranceData.
Все мои предложения были сбиты с большим воплем и скрежетом зубов. Приложение работает как спроектировано, и, хотя оно представляет собой большую грязь, все неприятные хаки, особые случаи и странные бизнес-правила саркастически и юмористически документированы в исходном коде.