Пользователи просят денормализованную базу данных - PullRequest
15 голосов
/ 13 ноября 2009

Я нахожусь на ранних стадиях разработки системы, управляемой базой данных, и большая часть системы вращается вокруг наследственного типа отношений. Существует родительская сущность с около 10 столбцами, и будет около 10 дочерних сущностей, унаследованных от родительской. Каждый дочерний объект будет иметь около 10 столбцов. Я подумал, что имеет смысл дать родительской сущности свою собственную таблицу и дать каждому дочернему элементу свои собственные таблицы - структуру таблицы на подкласс.

Сегодня мои пользователи попросили просмотреть структуру системы, которую я создал. Они отказались от идеи структуры таблицы на подкласс. Они предпочли бы одну большую таблицу столбцов ~ 100, потому что им было бы проще выполнять свои собственные пользовательские запросы.

Должен ли я рассмотреть вопрос о денормализации базы данных ради пользователей?

Ответы [ 13 ]

59 голосов
/ 13 ноября 2009

Абсолютно нет. Вы всегда можете создать представление позже, чтобы показать им то, что они хотят видеть.

13 голосов
/ 13 ноября 2009

Они фактически запрашивают отчет.

Вы могли бы предоставить им доступ к представлению , содержащему все поля, которые им требуются ... чтобы вы не испортили свою модель данных.

8 голосов
/ 13 ноября 2009

Нет. Правильно структурируйте данные, и если пользователям нужно денормализованное представление данных, создайте их как ВИД в базе данных.

В качестве альтернативы учтите, что, возможно, СУБД не является подходящим инструментом хранения для этого проекта.

5 голосов
/ 13 ноября 2009

По какой-то причине они являются пользователями, а не программистами системы. Предоставить отдельный интерфейс для своих запросов. Опытные пользователи, подобные этому, могут быть и полезны, и иметь дело с болью. Просто объясните, что вам нужна база данных, разработанная определенным образом, чтобы вы могли выполнять свою работу. Как только это будет выполнено, вы предоставите другие средства, чтобы упростить запросы.

4 голосов
/ 13 ноября 2009

Что они знают !? Можно утверждать, что пользователи вообще не должны иметь прямого доступа к базе данных.

Это делает вас открытыми для серьезных проблем с производительностью только потому, что несколько пользователей выполняют смешные запросы.

3 голосов
/ 13 ноября 2009

Помимо множества технических причин, по которым предложения ваших пользователей или против них, вы должны быть на той же странице, чтобы сообщать о последствиях различных сценариев и (что более важно) стоит этих последствий. Если пользователи являются вашими клиентами, и они платят вам за работу, объясните, что их ужасные"предложенные" идеи могут стоить им больше времени во время разработки, дополнительных аппаратных ресурсов и т. Д.

Надеюсь, вы сможете объяснить это таким образом, чтобы продемонстрировать свой опыт и понять, почему ваша идея гораздо полезнее для ваших пользователей в долгосрочной перспективе.

3 голосов
/ 13 ноября 2009

Как насчет того, чтобы создать VIEW в формате, который хотели пользователи, сохраняя при этом должным образом нормализованную таблицу?

2 голосов
/ 13 ноября 2009

Как все более или менее упомянули, в этом пути лежит безумие, и вы всегда можете построить представление.

Если вы просто не можете заставить их разобраться в этом вопросе, подумайте о том, чтобы показать им эту ветку и количество профессионалов, которые взвесили, сказав, что пользователи вмешиваются в вещи, которые они не полностью понимают, и влияние будет подорван фундамент.

Большая часть ремесла разработчика - это чувство того, что не сработает в долгосрочной перспективе, и правила нормализации в этом отношении почти каноничны. Есть ситуации, когда вам нужно денормализовать (хранилища данных и т. Д.), Но это не похоже на одно из них!

Это также звучит так, как будто у вас под рукой есть особенно тревожный бренд пользователя - любитель-разработчик, который думает, что они могли бы сделать вашу работу лучше, если бы у них было время. Это может или не может помочь, но я обнаружил, что эти типы хорошо реагируют на презентацию - теперь я обнаружил, что если я одеваюсь остро и показываю немного силы в моей личности, это помогает им чувствовать себя как Я эксперт и предотвращаю кучу проблем до того, как они начнутся.

1 голос
/ 13 ноября 2009

Я собираюсь сыграть здесь адвоката дьявола и сказать, что оба решения звучат как плохое приближение к фактическим данным. Есть причина, по которой объектно-ориентированные языки программирования не имеют тенденцию реализовываться ни с одной из этих моделей данных, и это не потому, что идеи Codd 1970 года об отношениях были идеальной системой для хранения и запроса объектно-ориентированных структур данных. : -)

Помните, что SQL изначально разрабатывался как язык пользовательского интерфейса (поэтому он выглядит смутно как английский, а не совсем как другие языки того времени: Algol, C, APL, Prolog). Единственные причины, по которым я слышал о том, что сегодня пользователи не выставляют базу данных SQL, - это безопасность (они могут отключить сервер!) И удобство использования (кто хочет писать SQL, когда можно щелкнуть мышью?), Но если это их сервер и они хотите, то почему бы не позволить им?

Учитывая, что "большая часть системы вращается вокруг типа наследования", я бы всерьез рассмотрел базу данных, которая позволяет мне представить это изначально, либо Postgres (если важен SQL) или собственная объектная база данных (с которой можно работать, если вам не нужна совместимость с SQL).

Наконец, помните, что каждое инженерное решение - это компромисс. «Придерживаясь своего оружия» (как кто-то еще предложил), вы неявно заявляете, что ценность желаний ваших пользователей равна нулю. Не спрашивайте SO о правильном ответе на это, потому что мы не знаем, что ваши пользователи хотят делать с вашими данными (или даже каковы ваши данные, или кто ваши пользователи). Скажите им, почему вы хотите решение с несколькими таблицами, а затем разработайте для них решение, приемлемое для вас обоих.

1 голос
/ 13 ноября 2009

Клиент всегда прав. Однако клиент, скорее всего, отступит, когда вы конвертируете его требование в долларов и центов . Таблица из 100 столбцов потребует дополнительного времени разработки для написания кода, который будет делать то, что база данных будет делать автоматически при правильной реализации. Кроме того, их затраты на поддержку будут выше , поскольку больше кода означает больше проблем и меньшую простоту отладки.

...