Ответ 1

Возможно, вам стоит посмотреть этот вопрос

Принятый ответ от Билла Карвина приводит к конкретным аргументам в отношении таблицы ключей/значений, обычно известной как значение атрибута сущности (EVA)

.. Хотя многие люди, похоже, предпочитают EAV, я этого не делаю. Кажется, что большинство гибкое решение, и, следовательно, Лучший. Однако, помните о поговорке TANSTAAFL. Вот некоторые из недостатки EAV:

• Невозможно сделать столбец обязательным (эквивалентно NOT NULL).
• Невозможно использовать типы данных SQL для проверки записей.
• Невозможно гарантировать, чтобы имена атрибутов были написаны последовательно.
• Невозможно поместить внешний ключ в значения любого атрибута, например. для таблицы поиска.
• Получение результатов в обычном табличном макете является сложным и дорого, потому что для получения атрибутов из нескольких строк, которые вам нужно сделать JOIN для каждого атрибута.

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

И в большинстве случаев это ненужно иметь такую ​​степень гибкости. В вопросе ОП о продукте типов, гораздо проще создать таблица по типу продукта для специфические для продукта атрибуты, так что вы имеют некоторую согласованную структуру принудительно, по крайней мере, для записей такой же тип продукта.

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

Ответ 2

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

Что, собственно, о EAV, "плохо"?

1 Введение

Есть разница между EAV, сделанным правильно, и сделано плохо, так же как разница между 3NF выполнена правильно и сделано плохо. В нашей технической работе мы должны точно знать, что работает, а что нет; о том, что хорошо работает, а что нет. Заявления о одеялах опасны, дезинформируют людей и тем самым препятствуют прогрессу и всеобщему пониманию соответствующих проблем.

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

Нормализация также часто неправильно понимается, поэтому слово об этом. Wiki и другие бесплатные источники фактически публикуют совершенно бессмысленные "определения", которые не имеют академической основы, которые имеют предвзятость поставщиков, чтобы проверить их нестандартные продукты. Существует Кодд опубликовал свои Двенадцать правил. Я реализую минимум 5NF, чего более чем достаточно для большинства требований, поэтому я буду использовать это как базовый уровень. Проще говоря, предполагая, что читатель читает Третью нормальную форму (по крайней мере это определение не смущает)...

2 Пятая нормальная форма

2.1 Определение

Пятая нормальная форма определяется как:

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

Я делаю различие в том, что это не значит, что база данных нормализована к определенному NF или нет; база данных просто нормализована. Это то, что каждая таблица имеет нормализуемое значение для конкретного NF: для некоторых таблиц может потребоваться только 1NF, другие 3NF, а другие - 5NF.

2.2 Производительность

Было время, когда люди думали, что нормализация не обеспечила производительность, и им пришлось "денормализовать для производительности". Слава Богу, этот миф был развенчан, и сегодня большинство ИТ-специалистов понимают, что нормализованные базы данных работают лучше. Производители баз данных оптимизируют для нормализованных баз данных, а не для файловых систем с денормированными файлами. Истина "денормализована", база данных НЕ была нормализована в первую очередь (и она выполнялась плохо), она была ненормализована, и они сделали некоторое дальнейшее скремблирование для повышения производительности. Для того, чтобы быть Денормализованным, он должен быть добросовестно нормализован первым и никогда не состоялся. Я переписал множество таких "денормализованных для производительности" баз данных, обеспечивая верную нормализацию и ничего больше, и они выполняли как минимум десять, а также сто, раз быстрее. Кроме того, они требовали лишь доли дискового пространства. Это так пешеходно, что я гарантирую упражнение в письменной форме.

2.3 Ограничение

Ограничения, или, скорее, полная степень 5NF:

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

3 Шестой нормальный вид

3.1 Определение

Шестая нормальная форма определяется как:

• Отношение (строка) - это первичный ключ плюс не более одного атрибута (столбец)

Он известен как неприводимая нормальная форма, конечная NF, потому что нет никакой дополнительной нормализации, которая может быть выполнена. Хотя это обсуждалось в академических кругах в середине девяностых годов, оно было официально объявлено только в 2003 году. Для тех, кто любит очернить формальность реляционной модели, путают отношения, реверы, "отношения" и т.п.: Вся эта ерунда может укладываться в постель, потому что формально указанное определение определяет неприводимое отношение, иногда называемое атомным соотношением.

3.2 Прогрессия

Приращение, которое предоставляет 6NF (что 5NF не имеет):

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

Позвольте мне сказать, что я (и другие) поставлял улучшенные 5NF-таблицы 20 лет назад, явно для поворота, без каких-либо проблем и, таким образом, позволяя (a) использовать простой SQL и (b) обеспечивая очень высокую производительность; было приятно узнать, что академические гиганты отрасли официально определили, что мы делаем. Ночевка, мои таблицы 5NF были переименованы в 6NF, без меня, поднимая палец. Во-вторых, мы сделали это только там, где нам это было нужно; опять же, это была таблица, а не база данных, которая была нормализована до 6NF.

3.3 Ограничение SQL

Это громоздкий язык, особенно re joins, и делает что-то умеренно сложное, делает его очень громоздким. (Это отдельная проблема, что большинство кодировщиков не понимают и не используют подзапросы.) Он поддерживает структуры, необходимые для 5NF, но только просто. Для надежных и стабильных реализаций необходимо внедрить дополнительные стандарты, которые могут частично состоять из дополнительных таблиц каталога. Дата "использования" для SQL прошла успешно и по-настоящему истекла в начале девяностых; он полностью лишен какой-либо поддержки для таблиц 6NF и отчаянно нуждается в замене. Но это все, что у нас есть, поэтому нам нужно просто справиться с этим.

Для тех из нас, кто применял стандарты и дополнительные таблицы каталогов, мы не пытались расширить наши каталоги, чтобы обеспечить возможности, необходимые для поддержки структур 6NF до стандарта: какие столбцы принадлежат к каким таблицам и в каком порядке; обязательное/факультативное; формат отображения; и т.д. По существу, полный каталог MetaData, вступающий в брак с каталогом SQL.

Обратите внимание, что каждый NF содержит в себе каждый предыдущий NF, поэтому 6NF содержит 5NF. Мы не нарушили 5NF, чтобы обеспечить 6NF, мы обеспечили переход от 5NF; и где SQL был коротким, мы предоставили каталог. Это означает, что основные ограничения, такие как внешние ключи; и Value Domains, которые были предоставлены посредством декларативной ссылочной целостности SQL; Типы данных; ПРОВЕРКИ; и ПРАВИЛА на уровне 5NF остались нетронутыми, и эти ограничения не были подорваны. Высокое качество и высокая производительность стандартных баз данных 5NF в любом случае не уменьшались путем введения 6NF.

3.4 Каталог

Важно защитить пользователей (любой инструмент отчетов) и разработчиков, от необходимости иметь дело с переходом с 5NF на 6NF (это их задача быть разработчиками кодирования приложений, это моя работа - быть разработчиком базы данных). Даже в 5NF это всегда было целью дизайна: правильно нормализованная база данных с минимальным каталогом данных на самом деле довольно проста в использовании, и я не собирался это делать. Имейте в виду, что из-за нормального обслуживания и расширения структуры 6NF меняются со временем, новые версии базы данных публикуются через регулярные промежутки времени. Без сомнения, SQL (уже громоздкий при 5NF), необходимый для построения строки 5NF из таблиц 6NF, еще более громоздкий. С благодарностью, это совершенно не нужно.

Поскольку у нас уже был наш каталог, который идентифицировал полный 6NF-DDL-that-SQL-does-not-обеспечить, если вы это сделаете, я написал небольшую утилиту для чтения каталога и:

• генерирует DDL-таблицу 6NF.
• генерирует 5NF VIEWS таблиц 6NF. Это позволило пользователям оставаться в блаженном неведении о них и дало им те же возможности и производительность, что и у 5NF
• генерирует полный SQL (а не шаблон, у нас есть эти отдельно), необходимые для работы с структурами 6NF, которые затем используют кодеры. Они освобождаются от скуки и повторения, которые в противном случае требуются, и могут сосредоточиться на логике приложения.

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

3.5 Производительность

У каждого есть свои "болезни", чтобы страдать, их крест нести; Я, кажется, одержим Performance. Мои базы данных 5NF хорошо зарекомендовали себя, поэтому позвольте мне заверить вас, что я провел гораздо больше тестов, чем это было необходимо, прежде чем размещать что-либо в производстве. База данных 6NF выполнялась точно так же, как и база данных 5NF, не лучше, не хуже. Это не удивительно, потому что единственное, что делает "сложный" 6NF SQL, что 5NF SQL не делает, выполняет гораздо больше объединений и подзапросов.

Вы должны изучить мифы.

• Любой, кто оценил проблему (например, рассмотрел планы выполнения запросов), будет знать, что Joins Cost Nothing, это разрешение времени компиляции, они не влияют на время выполнения.
• Да, конечно, количество соединенных таблиц; размер соединяемых таблиц; можно ли использовать индексы; распределение соединяемых ключей; и т.д., все стоят кое-что.
• Но само соединение ничего не стоит.
• Запрос в пяти (больших) таблицах в базе данных Unnormalised намного медленнее, чем эквивалентный запрос в десяти (меньших) таблицах в той же базе данных, если он был нормализован. Дело в том, что ни четыре, ни девять Джони ничего не стоят; они не фигурируют в проблеме производительности; выбранный набор в каждом соединении в нем фигурирует.

3.6 Преимущества

• Неограниченный столбчатый доступ. Именно здесь 6NF действительно выделяется. Прямой столбчатый доступ был настолько быстрым, что не нужно было экспортировать данные в хранилище данных, чтобы получить скорость от специализированных структур DW.

  Мое исследование нескольких DW, отнюдь не полное, показывает, что они последовательно хранят данные по столбцам, в отличие от строк, что и делает 6NF. Я консервативен, поэтому я не собираюсь делать никаких заявлений о том, что 6NF вытеснит DW, но в моем случае он устранил необходимость в одном.

• Было бы несправедливо сравнивать функции, доступные в 6NF, которые были недоступны в 5NF (например, Pivoting), которые, очевидно, выполнялись намного быстрее.

Это была наша первая настоящая база данных 6NF (с полным каталогом и т.д., в отличие от всегда 5NF с улучшениями только по мере необходимости, а позже получилось 6NF), и клиент очень доволен. Конечно, я отслеживал производительность в течение некоторого времени после родов, и я определил еще более быстрый метод столбчатого доступа для моего следующего проекта 6NF. Это, когда я это сделаю, может немного конкурировать за рынок DW. Клиент не готов, и мы не фиксируем то, что не нарушено.

3.7 Что, собственно, около 6NF, является "плохим"?

Обратите внимание: не все будут подходить к работе с такой же формальностью, структурой и соблюдением стандартов. Поэтому было бы глупо заключить из нашего проекта, что все базы данных 6NF хорошо работают и просты в обслуживании. Было бы так же глупо заключать (смотря на реализации других), что все базы данных 6NF работают плохо, их трудно поддерживать; бедствий. Как всегда, с любыми техническими усилиями конечная производительность и простота обслуживания строго зависят от формальности, структуры и соблюдения стандартов, в дополнение к соответствующему набору навыков.

3.8 Доступность

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

Я с удовольствием продолжаю отвечать на вопросы и предоставлять полезную информацию в каталоге 6NF, давать советы о том, что работает, а что нет и т.д., без фактического опубликования нашего IP (документации). Я также рад провести квалифицированные тесты для вас.

4 Значение атрибута сущности

Раскрытие информации: опыт. Я проверил несколько из них, в основном, больницы и медицинские системы. Я выполнил корректирующие задания на двух из них. Первоначальная доставка зарубежным провайдером была достаточно адекватной, хотя и не большой, но расширения, реализованные местным провайдером, были беспорядком. Но не почти катастрофа, которую люди разместили о re EAV на этом сайте. Несколько месяцев интенсивная работа исправила их красиво.

4.1 Что это такое

Для меня было очевидно, что реализации EAV, над которыми я работал, являются просто подмножествами шестой нормальной формы. Те, кто реализует EAV, делают это потому, что им нужны некоторые функции 6NF (например, возможность добавлять столбцы без изменений DDL), но у них нет академических знаний для реализации истинного 6NF, или стандартов и структур для его реализации и администрирования надежно. Даже оригинальный провайдер не знал о 6NF, или что EAV был подмножеством 6NF, но они с готовностью согласились, когда я указал на них. Поскольку структуры, необходимые для обеспечения EAV и, действительно, 6NF, эффективно и эффективно (каталоги; Views; автоматическое создание кода) официально не идентифицируются в сообществе EAV и отсутствуют в большинстве реализаций, я классифицирую EAV как ублюдочного сына Шестой нормальной формы.

4.2 Что, собственно, о EAV, "плохо"?

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

5 Nulls

Существует известная и документированная проблема под названием "Проблема с нулем". Это достойно эссе само по себе. Для этого сообщения достаточно сказать:

• проблема действительно является необязательным или отсутствующим значением; здесь рассмотрение является табличным дизайном, так что нет нулей или столбцов Nullable
• на самом деле это не имеет значения, потому что, независимо от того, используете ли вы Nulls/No Nulls/6NF, чтобы исключить отсутствующие значения, вам придется запрограммировать для этого, в точности проблема: обработка отсутствующих значений, которые нельзя обойти
  • за исключением, конечно, для чистого 6NF, что устраняет проблему Null
  • кодирование для обработки отсутствующих значений остается
    • кроме, с автоматизированной генерацией кода SQL, heh heh
• Nulls - плохая новость для оценки, и многие из нас решили несколько десятилетий назад не разрешать Nulls в базе данных (Nulls в переданных параметрах и наборах результатов, чтобы указать отсутствующие значения, в порядке)
  • что означает набор нулевых заместителей и булевых столбцов для указания отсутствующих значений
• Nulls заставляют иначе фиксированные столбцы len быть переменными len; переменные столбцы len должны никогда использоваться в индексах, потому что небольшая "распаковка" должна выполняться при каждом доступе каждой записи индекса во время обхода или погружения.

6 Позиция

Я не сторонник EAV или 6NF, я сторонник качества и стандартов. Моя позиция:

• Всегда, во всех отношениях, делайте все, что вы делаете, с самым высоким стандартом, о котором вы знаете.

• Нормализация до третьей нормальной формы минимальна для реляционной базы данных (5NF для меня). DataTypes, декларативная ссылочная целостность, транзакции, нормализация - все основные требования к базе данных; если они отсутствуют, это не база данных.

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

• Нет необходимости выполнять дополнительную работу. Если ваше требование может быть выполнено с помощью 5NF, не используйте больше. Если вам нужны дополнительные значения или возможность добавлять столбцы без изменений DDL или полное устранение Null Problem, реализуйте 6NF только в тех таблицах, которые в них нуждаются.

• Если вы это сделаете, из-за того, что SQL не обеспечивает надлежащую поддержку для 6NF, вам необходимо реализовать:

  • простой и эффективный каталог (смешение столбцов и потеря целостности данных просто неприемлемы)
  • 5NF-доступ для таблиц 6NF через VIEWS, чтобы изолировать пользователей (и разработчиков) от обремененных (не "сложных" ) SQL
  • напишите или купите утилиты, чтобы вы могли создавать громоздкий SQL для построения строк 5NF из таблиц 6NF и избегать создания таких же
  • измерять, контролировать, диагностировать и улучшать. Если у вас есть проблемы с производительностью, вы сделали либо (a) ошибку нормализации, либо (b) ошибку кодирования. Период. Сделайте резервную копию нескольких шагов и исправьте.

• Если вы решите пойти с EAV, узнайте его, что это такое, 6NF и выполните его правильно, как указано выше. Если вы это сделаете, у вас будет успешный проект, гарантированный. Если вы этого не сделаете, у вас будет гарантированный завтрак.

6.1 Нет такой вещи, как бесплатный обед

Эта пословица упоминается, но на самом деле она была использована неправильно. Способ, которым он на самом деле, глубоко применим, как и выше: если вы хотите воспользоваться преимуществами 6NF/EAV, вам лучше также выполнить работу, необходимую для ее получения (каталог, стандарты). Конечно, следствие состоит в том, что если вы не выполняете работу, вы не получите выгоду. Отсутствует "потеря" типов данных; ценность доменов; Иностранные ключи; Проверки; Правила. Что касается производительности, то для 6NF/EAV нет штрафа за производительность, но всегда существует существенный штраф за производительность для нестандартных работ.

7 Конкретный вопрос

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

• Не используйте EAV (или 6NF, если на то пошло)
• Не используйте столбцы Nulls или Nullable (если вы не хотите подорвать производительность)
• Использовать единую таблицу оплаты для общих столбцов оплаты.
• и дочерняя таблица для каждого типа PaymentType, каждая со своими конкретными столбцами

• Все полностью типичные и ограниченные.

• Что это за "еще один row_id"? Почему некоторые из вас придерживаются удостоверения личности во всем, что движется, не проверяя, является ли он оленем или орлом? Нет.Ребенок - зависимый ребенок. Отношение 1:: 1. PK ребенка - это PK родителя, общая таблица платежей. Это обычный супертип-подтип, дифференциатор - PaymentTypeCode. Подтипы и супертипы являются обычной частью реляционной модели и полностью удовлетворяются в базе данных, а также в любом хорошем инструменте моделирования.

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

Спасибо, что остался со мной до конца.

A. Ответы на комментарии

A.1 Атрибуция

Я заявляю, что "я верен RM" и, ссылаясь на "гигантов промышленности", я предположил, что ИТ-специалисты поймут, что это значит. Смиренные извинения.

• У меня нет личных или частных или специальных определений. Все утверждения относительно определения (например, императивы):
  
  • Нормализация,
  • Нормальные формы и
  • Реляционная модель.
    .
    см. многие оригинальные тексты. EF Codd и CJ Date (недоступно в Интернете)
    .
    Последние временные данные и реляционная модель от CJ Date, Хью Дарвен, Никос Лоренцос
    .
    и ничего, кроме тех текстов .
    "Я стою на плечах гигантов"
    ,
• Сущность, тело, все утверждения относительно реализации (например, субъективного и первого лица) из вышеперечисленного основаны на опыте; внедряя вышеуказанные принципы и концепции, как коммерческую организацию (консультант, нанятый или работающий консультантом), в крупных финансовых учреждениях в Америке и Австралии более 32 лет.
  
  • Это включает в себя множество больших назначений, исправляющих или заменяющих нестандартные или нереляционные реализации.
    ,
• Нулевая проблема по отношению к шестой нормальной форме
  Свободно доступная "Белая книга", относящаяся к названию (она не определяет проблему "Нуль" ), находится по адресу: http://www.dcs.warwick.ac.uk/~hugh/TTM/Missing-info-without-nulls.pdf.
  .
  "Определение ореховой скорлупы" 6NF (имеющее смысл для тех, кто знаком с другими NF), можно найти на p6

A.2 Поддержка доказательств

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

• Вот несколько документов, на которые я могу положить руки немедленно, чтобы начать (я нахожусь в назначении в Новой Зеландии, предоставит больше через пару дней, имена клиентов должны быть запутаны).

  а. Большой банк
  Это лучший пример, поскольку это было сделано для явных причин в этой статье, и цели были реализованы. У них был бюджет для Sybase IQ (продукт DW), но отчеты были такими быстрыми, когда мы закончили проект, они им не нужны. Торговой аналитической статистикой были мои 5NF плюс поворотные расширения, которые, как оказалось, были 6NF, описанные выше. Я думаю, что на все вопросы, заданные в комментариях, был дан ответ в документе, за исключением:
    - количество строк:
    - старая база данных неизвестна, но ее можно экстраполировать из других статистических данных
    - новая база данных = 20 таблиц по 100M, 4 таблицы по 10B.

  б. Малый финансовый институт, часть A
  Часть B - Мясо Часть C - Связанные диаграммы
  Часть D- Приложение, аудит индексов до и после (1 строка за индекс)
  Обратите внимание на четыре документа; четвертый - только для тех, кто хочет проверить подробные изменения Индекса. Они запускали стороннее приложение, которое не могло быть изменено, потому что у локального поставщика не было бизнеса, плюс 120% расширений, которые они могли, но не хотели, менять. Мы были вызваны из-за того, что они обновились до новой версии Sybase, которая была намного быстрее, что привело к изменению различных пороговых значений производительности, что вызвало большой беспорядок. Здесь мы нормализуем абсолютно все на сервере кроме модели db, с целью (заранее гарантированной) устранения взаимоблокировок (извините, я не собираюсь объяснять, что здесь: люди, которые спорят о "денормализации", вопрос, будет в розовом прилегании к этому). Он включал отмену "разбиения таблиц на архив db для производительности", который является предметом другого сообщения (да, новая отдельная таблица выполняется быстрее, чем две пролитые). Это упражнение применимо к MS SQL Server [insert rewrite version].

  с. Госпиталь Йельского университета в Нью-Хейвене
  Это Йельская школа медицины, их учебная больница. Поддерживал их в течение многих лет. Стороннее приложение поверх Sybase. Проблема со статистикой заключается в том, что 80% времени они собирали моментальные снимки только в номинированных тестовых временах, но не имеют постоянной истории, поэтому нет "до изображения", чтобы сравнить нашу новую согласованную статистику. Я не знаю никого другого, который мог бы получить внутреннюю статистику Unix и Sybase на одних и тех же графиках в автоматическом режиме. Теперь сеть является порогом (доверие читателя к пониманию того, что это хорошая вещь).

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

A.3 Длина

• Я не извиняюсь за длину или за конденсированную природу. Люди с небольшим охватом внимания (без обид, это реальность в наши дни), или которые не знакомы с реляционной технологией или терминологией, должны относиться к исходным текстам или к сторонникам упомянутой технологии.
• По определению, это исключает Wiki и всех, кто осуждает указанную технологию, например плакаты, на которые эта почта является ответом. Слон не может определить газель; и если они постулируют о жизни газелей, мы не должны их слушать.

Ответ 3

Принцип My # 1 - это не переделывать что-то без причины. Поэтому я бы пошел с вариантом 1, потому что это ваш текущий дизайн, и у него есть проверенный послужной список работы.

Потратьте время редизайна на новые функции.

Ответ 4

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

Ни в коем случае нельзя использовать таблицу EAV для чего-то подобного. Они ужасны для запросов и производительности, а гибкость переоценивается (спросите пользователей, предпочитают ли они добавлять новые типы 3-4 раза в год без изменения программы за счет ежедневной производительности).

Ответ 5

На первый взгляд, я бы пошел на вариант 2 (или 3): по возможности обобщил. Вариант 4 не очень реляционный, я думаю, и сделаю ваши запросы сложными. Когда вы столкнулись с этим вопросом, я, как правило, сталкиваюсь с этими вариантами с "вариантами использования":
- как работает 2/3 при выполнении этой или этой операции?