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

Что Именно, насчет подслушивания, это "плохо"?

1. Введение

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

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

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

2 Пятая Нормальная Форма

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

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

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

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

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

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

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

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

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

3 Шестая Нормальная Форма

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

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

• связь (строка) является первичным ключом плюс не более одного атрибута (столбца)

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

3.2 прогрессии

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

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

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

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

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

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

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

3.4 каталог

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

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

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

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

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

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

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

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

3.6 Выгода

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

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

2. было бы несправедливо сравнивать функции, доступные в 6NF, которые были недоступны в 5NF (например. Поворот), который, очевидно, бежал намного быстрее.

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

3.7 что, собственно, о 6NF, "плохо"?

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

3.8 наличие

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

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

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

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

4.1 Что Это Такое

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

4.2 что именно в подслушивании "плохо"?

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

5 нулями

существует хорошо известная и документированная проблема, называемая проблемой Null. Она сама по себе достойна эссе. Для этого поста достаточно сказать:

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

6 место

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А. ответы на Комментарии

A. 1 Attribution

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

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

А. 2 Вспомогательная Доказательства!--2-->

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

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

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

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

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

просто что-то для начала, что было очищено для публикации. Еще позже. Ок, давайте немного доказательств того, что "denormalisation' повышает производительность" и т. д. Ваш ход.

A. 3 Длина

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

мой принцип № 1 - не переделывать что-то без причины. Так что я бы выбрал вариант 1, потому что ваш текущий дизайн и имеет успешный опыт работы.

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

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

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

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