Пользователи, просящие денормализованную базу данных

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

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

Чтобы внести ясность: я лично предпочитаю метод таблицы для каждого подкласса, но я не

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

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

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

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

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

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

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

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

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

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

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

How about if you created a VIEW in the format your users wanted while still maintaining a properly normalized table?

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

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

Итак, учитывая эти недостатки параметра представления и мы уже думаем об их устранении, начав Чтобы сделать копии данных, я бы рассмотрел следующий вариант - создать отдельную версию данных только для чтения (для этих пользователей), которая имеет другую структуру. Обычно я сначала смотрю на звездную схему в стиле Кимбалла. Вам не нужно иметь полноценное хранилище данных, согласованное по времени. Конечно, это вариант, но вы можете просто поддерживать модель отчетности в актуальном состоянии с данными. Звездные схемы представляют собой особую форму денормализации и особенно хороши для числовых отчетов, и пользователи не должны случайно злоупотреблять данной звездой. Вы можете поддерживать звезду в актуальном состоянии несколькими способами, включая триггеры, запланированные задания и т. Д. Они могут быть очень быстрыми для создания отчетов и запускаться в одной производственной установке - возможно, в отдельном экземпляре, если не в отдельной базе данных.

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

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

Есть много способов снять шкуру с этих кошек. Удачи.

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

Есть много способов снять шкуру с этих кошек. Удачи.

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

Есть много способов снять шкуру с этих кошек. Удачи.

What do they know!? You could argue that users shouldn't even be having direct access to a database in the first place.

Doing that leaves you open to massive performance issues, just because a couple of users are running ridiculous queries.

They are the users and not the programmers of the system for a reason. Provide a separate interface for their queries. Power users like this can both be helpful and a pain to deal with. Just explain you need the database designed a certain way so you can do your job, period. Once that is accomplished you and provide other means to make querying easier.

No. Structure the data properly and if the users need the a denormalized view of the data create it as a VIEW in the database.

Alternatively, consider that perhaps an RDBMS is not the appropriate storage tool for this project.

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

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