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

Ответ 1

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

Ответ 2

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

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

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

Ответ 6

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

Ответ 7

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

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

Ответ 8

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

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

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

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

Ответ 9

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

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

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

Ответ 10

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

Однако в некоторых случаях это может повлиять на производительность, если представление сложное или интенсивное. С плохо написанными запросами пользовательских запросов он также может задерживать блокировки дольше или увеличиваться дальше, чем при более эффективном запросе. Также пользователи могут неправильно интерпретировать модель данных E-R и производить умноженные числа в случаях, когда есть отношения "много-к-одному" или "многие ко многим". Следующий вариант может состоять в том, чтобы материализовать эти представления с помощью индексов или сделать таблицы и обновить их, что приблизит нас к моей следующей опции...

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

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

Некоторые архитекторы часто удваивают свои серверы и используют модель SAME с некоторой репликацией, чтобы обеспечить сервер отчетов, который индексируется более сильно или по-разному. Такой второй сервер не влияет на производственные операции с требованиями к отчетности и может быть легко обновлен. Будет только одна модель, но, конечно же, у нее будут те же проблемы с удобством использования, что позволяет пользователям только ad hoc доступа к базовой модели, без влияния производительности, поскольку они получают свою собственную площадку.

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

Ответ 11

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

Ответ 12

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

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

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

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

Ответ 13

Вы внедрили Наследование классов таблицы, и они просят Наследование отдельных таблиц. Оба варианта действительны в определенных ситуациях.

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