Каковы преимущества [dis] использования таблицы ключ / значение по сравнению со столбцами или отдельными таблицами, которые могут содержать значения NULL?
Я модернизирую систему управления платежами, которую создал недавно. В настоящее время у него есть одна таблица для каждого типа оплаты, которую он может принять. Он ограничен возможностью заплатить только за одну вещь, которую облегчает это обновление. Я просил предложения относительно того, как я должен проектировать это, и у меня есть эти основные идеи для работы:
- Имейте одну таблицу для каждого типа оплаты, с несколькими общими столбцами на каждом. (текущий дизайн)
- Координируйте все платежи с центральной таблицей, которая принимает общие столбцы (объединяющие идентификаторы платежей независимо от типа) и идентифицирует другую таблицу и идентификатор строки, столбцы которых предназначены для этого типа платежей.
- Иметь одну таблицу для всех типов платежей и обнулять столбцы, которые не используются ни для одного данного типа.
- Используйте идею центральной таблицы, но храните специализированные столбцы в таблице ключ / значение.
Мои цели для этого: не смехотворно медленные, максимально самодокументируемые и максимизация гибкости при сохранении других целей.
Мне не очень нравится 1 из-за повторяющихся столбцов в каждой таблице. Он отражает классы типов платежей, наследующие базовый класс, который обеспечивает функциональность для всех типов платежей... ORM наоборот?
Я больше всего склоняюсь к 2, потому что он так же "безопасен от типов" и самодокументирован, как и текущий дизайн. Но, как и в случае с 1, чтобы добавить новый тип оплаты, мне нужно добавить новую таблицу.
Мне не нравится 3 из-за "потраченного впустую места", и не сразу понятно, какие столбцы используются для каких типов платежей. Документация может немного облегчить эту проблему, но внутренние инструменты моей компании не имеют эффективного метода для хранения / поиска технической документации.
Аргумент, который я привел для 4, заключался в том, что это уменьшило бы необходимость изменения базы данных при добавлении нового метода оплаты, но оно страдает даже хуже, чем 3 из-за отсутствия явности. В настоящее время изменение базы данных не является проблемой, но это может стать логистическим кошмаром, если мы решим начать позволять клиентам поддерживать свою собственную базу данных в будущем.
Так что, конечно, у меня есть свои предубеждения. У кого-нибудь есть идеи получше? Какой дизайн, по вашему мнению, подходит лучше всего? На каких критериях я должен основывать свое решение?
5 ответов
Возможно, вам стоит посмотреть этот вопрос
В принятом ответе Билла Карвина приводятся конкретные аргументы против таблицы ключ / значение, обычно называемой значением атрибута сущности (EVA).
.. Хотя многие люди предпочитают EAV, я нет. Похоже, самое гибкое решение и, следовательно, лучшее. Однако имейте в виду пословицу TANSTAAFL. Вот некоторые из недостатков EAV:
- Нет способа сделать столбец обязательным (эквивалент
NOT NULL
).- Нет способа использовать типы данных SQL для проверки записей.
- Нет способа гарантировать, что имена атрибутов пишутся последовательно.
- Нет способа поместить внешний ключ в значения любого заданного атрибута, например, для таблицы поиска.
- Извлечение результатов в обычном табличном макете является сложным и дорогостоящим, потому что для получения атрибутов из нескольких строк вам нужно сделать
JOIN
для каждого атрибута.Степень гибкости, которую дает вам EAV, требует жертв в других областях, что, вероятно, делает ваш код более сложным (или хуже), чем это было бы для решения исходной проблемы более традиционным способом.
И в большинстве случаев нет необходимости иметь такую степень гибкости. В вопросе OP о типах продуктов гораздо проще создать таблицу для каждого типа продукта для атрибутов, относящихся к конкретному продукту, поэтому у вас есть некоторая согласованная структура, применяемая, по крайней мере, для записей того же типа продукта.
Я бы использовал EAV, только если каждая строка должна иметь возможность иметь отдельный набор атрибутов. Когда у вас есть конечный набор типов продуктов, EAV является излишним. Наследование таблиц классов будет моим первым выбором.
Заметка
Эта тема обсуждается, и на эту ветку ссылаются в других темах, поэтому я отнесся к ней разумно, пожалуйста, потерпите меня. Мое намерение состоит в том, чтобы обеспечить понимание, чтобы вы могли принимать обоснованные решения, а не упрощенные, основанные только на ярлыках. Если вы находите это интенсивным, читайте его кусками на досуге; возвращайся, когда голоден, а не раньше.
Что, собственно, о EAV, является "плохим"?
1. Введение
Есть разница между EAV, сделанным правильно и сделанным плохо, точно так же, как есть разница между 3NF, сделанным правильно и сделанным плохо. В нашей технической работе мы должны быть точными о том, что именно работает, а что нет; о том, что хорошо, а что нет. Общие заявления опасны, дезинформируют людей и, таким образом, препятствуют прогрессу и всеобщему пониманию соответствующих вопросов.
Я не за или против чего-либо, кроме плохой реализации неквалифицированными работниками и искажения уровня соответствия стандартам. И там, где я вижу недоразумение, как здесь, я попытаюсь устранить его.
Нормализацию также часто неправильно понимают, так что об этом. Вики и другие бесплатные источники на самом деле публикуют совершенно бессмысленные "определения", которые не имеют академической основы, которые имеют пристрастия вендоров для проверки своих нестандартных продуктов. Там Кодд опубликовал свои Двенадцать Правил. Я применяю минимум 5NF, что более чем достаточно для большинства требований, поэтому я буду использовать это в качестве основы. Проще говоря, предполагая, что третья нормальная форма понята читателю (по крайней мере, это определение не перепутано) ...
2 Пятая Нормальная Форма
2.1 Определение
Пятая нормальная форма определяется как:
- каждый столбец имеет отношение 1::1 с первичным ключом, только
- и ни к какому другому столбцу, в таблице или в любой другой таблице
- результат - не дублированные столбцы, нигде; Нет аномалий обновления (нет необходимости в триггерах или сложном коде, чтобы гарантировать, что при обновлении столбца его дубликаты обновляются правильно) .
- это повышает производительность, потому что (а) это влияет на меньшее количество строк и (б) улучшает параллелизм благодаря уменьшенной блокировке
Я делаю различие, это не то, что база данных нормализована к определенной NF или нет; база данных просто нормализована. Дело в том, что каждая таблица нормализована к определенной NF: для некоторых таблиц может потребоваться только 1NF, для других - 3NF, а для других - 5NF.
2.2 Производительность
Было время, когда люди думали, что нормализация не обеспечивает производительность, и им приходилось "снижать производительность". Слава Богу, что этот миф развенчан, и большинство ИТ-специалистов сегодня понимают, что нормализованные базы данных работают лучше. Поставщики баз данных оптимизируют работу с нормализованными базами данных, а не с денормализованными файловыми системами. Правда "денормализована" заключается в том, что база данных НЕ была нормализована во-первых (и она работала плохо), она была ненормализована, и они предприняли некоторые дополнительные меры для повышения производительности. Для того, чтобы быть денормализованным, он должен быть сначала точно нормализован, а этого никогда не было. Я переписал множество таких "денормализованных для производительности" баз данных, обеспечивающих точную нормализацию и ничего более, и они работали как минимум в десять, а в сто раз быстрее. Кроме того, им требуется только часть дискового пространства. Он настолько пешеходный, что я гарантирую выполнение упражнения в письменном виде.
2.3 Ограничение
Ограничения, или, скорее, полная степень 5NF это:
- он не обрабатывает необязательные значения, и необходимо использовать Null (многие разработчики запрещают Null и используют заменители, но это имеет ограничения, если оно не реализовано должным образом и согласованно)
- вам все еще нужно изменить DDL, чтобы добавить или изменить столбцы (и появляется все больше и больше требований по добавлению столбцов, которые не были первоначально определены после реализации; управление изменениями обременительно)
- хотя и обеспечивает наивысший уровень производительности благодаря нормализации (читай: устранение дубликатов и запутанных отношений), сложных запросов, таких как поворот (создание отчета по строкам или сводок по строкам, выраженным в виде столбцов) и "доступ к столбцам", как требуется для Операции с хранилищами данных являются сложными, и только эти операции не дают хороших результатов. Не потому, что это связано только с доступным уровнем навыков SQL, а не с движком.
3 Шестая Нормальная Форма
3.1 Определение
Шестая нормальная форма определяется как:
- Отношение (строка) - это первичный ключ плюс максимум один атрибут (столбец)
Он известен как Неприводимая Нормальная Форма, конечная НФ, потому что нет никакой дальнейшей Нормализации, которая может быть выполнена. Хотя это обсуждалось в научных кругах в середине девяностых, оно было официально объявлено только в 2003 году. Для тех, кто любит клеветать на формальность реляционной модели, путая отношения, релевары, "отношения" и тому подобное: все, что может вздор укладываться в постель, потому что формально вышеприведенное определение идентифицирует неприводимое отношение, иногда называемое атомным отношением.
3.2 Прогрессия
Приращение, которое обеспечивает 6NF (что не дает 5NF):
- формальная поддержка необязательных значений и, таким образом, устранение нулевой проблемы
- побочный эффект, столбцы могут быть добавлены без изменений DDL (подробнее позже)
- поворот без усилий
- простой и прямой колоночный доступ
- это позволяет (не в его ванильной форме) еще более высокий уровень производительности в этом отделе
Позвольте мне сказать, что я (и другие) поставлял улучшенные таблицы 5NF 20 лет назад, явно для поворота, без каких-либо проблем, и таким образом позволил (а) использовать простой SQL и (б) обеспечить очень высокую производительность; было приятно узнать, что академические гиганты отрасли формально определили, что мы делаем. Ночью мои 5NF столы были переименованы в 6NF, и я не поднял палец. Во-вторых, мы делали это только там, где это было нужно; опять же, это была таблица, а не база данных, которая была нормализована до 6NF.
3.3 Ограничение SQL
Это громоздкий язык, особенно повторное соединение, и выполнение чего-либо достаточно сложного делает его очень громоздким. (Это отдельная проблема, которую большинство кодеров не понимают или не используют подзапросы.) Он поддерживает структуры, необходимые для 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-что-SQL-не-предоставить-если хотите, я написал небольшую утилиту для чтения каталога и:
- сгенерировать таблицу 6NF DDL.
- генерировать 5NF VIEWS из 6NF таблиц. Это позволило пользователям оставаться в блаженном неведении о них, и дать им те же возможности и производительность, что и в 5NF.
- генерировать полный SQL (не шаблон, у нас он есть отдельно), необходимый для работы со структурами 6NF, которые затем используют кодеры. Они освобождаются от скуки и повторений, которые в противном случае требуются, и могут свободно концентрироваться на логике приложения.
Я не написал утилиту для Pivoting, потому что сложность, присутствующая в 5NF, устранена, и их теперь просто написать, как и в 5NF-Improved-for-Pivoting. Кроме того, большинство инструментов отчетов обеспечивают поворот, поэтому мне нужно только предоставить функции, которые включают в себя большое количество статистики, которую необходимо выполнить на сервере перед отправкой клиенту.
3.5 Производительность
У каждого есть своя "болезнь" страдания, свой крест, чтобы нести; Я был одержим Производительностью. Мои базы данных 5NF работали хорошо, поэтому позвольте мне заверить вас, что я запустил гораздо больше тестов, чем было необходимо, прежде чем что-то запускать в производство. База данных 6NF работает точно так же, как база данных 5NF, не лучше и не хуже. Это неудивительно, потому что единственное, что делает "сложный" 6NF SQL, а 5NF SQL не выполняет, - это выполняет гораздо больше соединений и подзапросов.
Вы должны изучить мифы.
- Любой, кто оценил проблему (т. Е. Изучил планы выполнения запросов), будет знать, что соединения ничего не стоят, это разрешение во время компиляции, они не влияют на время выполнения.
- Да, конечно, количество столов, к которым присоединяются; размер соединяемых таблиц; можно ли использовать индексы; распределение ключей, к которым присоединяются; и т.д., все что-то стоит.
- Но само соединение ничего не стоит.
- Запрос к пяти (большим) таблицам в ненормализованной базе данных намного медленнее, чем эквивалентный запрос к десяти (меньшим) таблицам в той же базе данных, если бы он был нормализован. Дело в том, что ни четыре, ни девять джинов не стоят ничего; они не фигурируют в проблеме производительности; выбранный набор в каждом соединении фигурирует в нем.
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 Значение атрибута сущности
Раскрытие: опыт. Я проверил некоторые из них, в основном больничные и медицинские системы. Я выполнил корректирующие задания по двум из них. Первоначальная поставка зарубежным провайдером была вполне адекватной, хотя и незначительной, но расширения, реализованные местным провайдером, были беспорядочными. Но совсем не беда, которую люди разместили на сайте. Несколько месяцев напряженной работы хорошо их наладили.
4.1 Что это такое
Для меня было очевидно, что реализации EAV, над которыми я работал, являются лишь подмножествами Шестой Нормальной Формы. Те, кто внедряет EAV, делают это потому, что им нужны некоторые функции 6NF (например, возможность добавлять столбцы без изменений DDL), но у них нет академических знаний для реализации настоящего 6NF или стандартов и структур для его реализации и администрирования. безопасно. Даже первоначальный поставщик не знал о 6NF или о том, что EAV был подмножеством 6NF, но они с готовностью согласились, когда я указал им на это. Поскольку структуры, требуемые для обеспечения EAV, а в действительности и 6NF, эффективно и действенно (каталог; Представления; автоматическая генерация кода) формально не определены в сообществе EAV и отсутствуют в большинстве реализаций, я классифицирую EAV как ублюдочного сына Шестую нормальную форму,
4.2 Что, собственно, EAV, является "плохим"?
Судя по комментариям в этой и других темах, да, EAV, сделанный плохо, - это катастрофа. Более важно (а) они настолько плохи, что производительность, обеспечиваемая в 5NF (забыть 6NF), теряется и (б) обычная изоляция от сложности не была реализована (кодеры и пользователи "вынуждены" использовать громоздкую навигацию) . И если бы они не реализовали каталог, все виды предотвратимых ошибок не были бы предотвращены. Все это может быть справедливо для плохих (EAV или других) реализаций, но это не имеет ничего общего с 6NF или EAV. Два проекта, над которыми я работал, имели вполне адекватную производительность (конечно, ее можно было улучшить; но не было плохой производительности благодаря EAV) и хорошую изоляцию сложности. Конечно, они не были близки к качеству или производительности моих баз данных 5NF или моей настоящей базы данных 6NF, но они были достаточно честными, учитывая уровень понимания опубликованных проблем в сообществе EAV. Они не были бедствиями и бессмысленной чепухой, которую якобы считали EAV на этих страницах.
5 нулей
Существует хорошо известная и задокументированная проблема под названием "Нулевая проблема". Это достойно эссе само по себе. Для этого поста достаточно сказать:
- проблема действительно необязательная или отсутствует; здесь рассматривается дизайн таблицы таким образом, что столбцы Null vs Nullable отсутствуют
- на самом деле это не имеет значения, потому что независимо от того, используете ли вы Nulls/No Nulls/6NF для исключения пропущенных значений, вам придется кодировать для этого, проблема именно в этом, обрабатывает пропущенные значения, которые нельзя обойти
- кроме, конечно, для чистого 6NF, который устраняет проблему с нулевым значением
- код для обработки пропущенных значений остается
- кроме того, с автоматической генерацией кода SQL, хе-хе
- Нулевые значения являются плохой новостью для производительности, и многие из нас десятилетия назад решили не допускать нулевые значения в базу данных (нулевые значения в переданных параметрах и наборах результатов для обозначения пропущенных значений вполне подходят)
- что означает набор пустых заменителей и логических столбцов для обозначения пропущенных значений
- Нулевые значения приводят к тому, что столбцы len с фиксированной длиной будут переменными len; переменные столбцы len никогда не должны использоваться в индексах, потому что небольшая "распаковка" должна выполняться при каждом доступе к каждой записи индекса, во время обхода или погружения.
6 позиций
Я не сторонник EAV или 6NF, я сторонник качества и стандартов. Моя позиция:
Всегда, во всех отношениях, делайте все, что вы делаете, в соответствии с самыми высокими стандартами, которые вы знаете.
Нормализация до третьей нормальной формы минимальна для реляционной базы данных (5NF для меня). DataTypes, декларативная ссылочная целостность, транзакции, нормализация - все это основные требования базы данных; если они отсутствуют, это не база данных.
- Если вам нужно "денормализовать для производительности", вы допустили серьезные ошибки нормализации, ваш дизайн не нормализован. Период. Не "денормализовать", наоборот, учиться нормализации и нормализации.
Нет необходимости делать дополнительную работу. Если ваше требование может быть выполнено с 5NF, не реализуйте больше. Если вам нужны дополнительные значения или возможность добавлять столбцы без изменений DDL или полного устранения нулевой проблемы, используйте 6NF только в тех таблицах, в которых они нужны.
Если вы это сделаете, только из-за того, что SQL не обеспечивает надлежащую поддержку 6NF, вам нужно будет реализовать:
- простой и эффективный каталог (перепутывание столбцов и потеря целостности данных просто недопустимы)
- 5NF-доступ к таблицам 6NF через VIEWS, чтобы изолировать пользователей (и разработчиков) от обремененного (не "сложного") SQL
- напишите или купите утилиты, чтобы вы могли сгенерировать громоздкий SQL для построения строк 5NF из таблиц 6NF и избежать написания одинаковых
- измерять, контролировать, диагностировать и улучшать. Если у вас есть проблемы с производительностью, вы сделали (а) ошибку нормализации или (б) ошибку кодирования. Период. Сделайте резервную копию нескольких шагов и исправьте это.
Если вы решите использовать EAV, узнайте, что это такое, 6NF, и правильно его примените, как описано выше. Если вы это сделаете, у вас будет успешный проект, гарантировано. Если вы этого не сделаете, вы будете иметь собачий завтрак, гарантировано.
6.1 Там нет такого понятия, как бесплатный обед
Эта пословица упоминалась, но на самом деле она использовалась неправильно. То, как это на самом деле глубоко применимо, описано выше: если вы хотите использовать преимущества 6NF/EAV, вам лучше быть готовым выполнить работу, необходимую для его получения (каталог, стандарты) . Конечно, следствие состоит в том, что, если вы не выполняете работу, вы не получите выгоду. Здесь нет "потери" типов данных; стоимость доменов; Внешние ключи; Проверки; Правила. Что касается производительности, то для 6NF / EAV нет снижения производительности, но всегда есть существенное снижение производительности для скользкой нестандартной работы.
7 Конкретный вопрос
В заключение. С учетом вышеизложенного контекста и того, что это небольшой проект с небольшой командой, нет никаких сомнений:
- Не используйте EAV (или 6NF в этом отношении)
- Не используйте пустые или пустые столбцы (если вы не хотите подорвать производительность)
- Используйте единую таблицу платежей для общих столбцов платежей
- и дочерняя таблица для каждого PaymentType, каждый со своими конкретными столбцами
Все полностью типизировано и ограничено.
Что это за бизнес "еще один row_id"? Почему некоторые из вас прикрепляют удостоверение личности ко всему, что движется, не проверяя, является ли это оленем или орлом? Нет, ребенок является зависимым ребенком. Соотношение 1::1. PK ребенка - это PK родителя, общая таблица платежей. Это обычный кластер Supertype-Subtype, дифференциатором является PaymentTypeCode. Подтипы и супертипы являются обычной частью реляционной модели и полностью учитываются в базе данных, а также в любом хорошем инструменте моделирования.
Конечно, люди, которые не знакомы с реляционными базами данных, думают, что изобрели его 30 лет спустя, и называют его забавными новыми именами. Или, что еще хуже, они сознательно переименуют его и заявляют, что это их собственные. Пока какой-то бедняга, с небольшим образованием и профессиональной гордостью, не разоблачает невежество или мошенничество. Я не знаю, кто это, но это один из них; Я просто констатирую факты, которые легко подтвердить.
Спасибо, что остался со мной до конца.
А. Ответы на комментарии
А.1 Атрибуция
Заявив, что "я верен РМ", и ссылаясь на "Гиганты отрасли", я предположил, что ИТ-специалисты поймут, что это значит. Смиренные извинения.
- У меня нет личных или частных или специальных определений. Все заявления относительно определения (например, императивы):
- Нормализация,
- Нормальные формы и
- Реляционная модель.
,
см. множество оригинальных текстов Э.Ф. Кодда и С.Дж. Дейта (недоступно бесплатно в Интернете)
,
Последними из них являются " Временные данные" и "Реляционная модель". Авторы: CJ Date, Hugh Darwen, Nikos A Lorentzos
,
и ничего кроме этих текстов
,
"Я стою на плечах гигантов"
,
- Суть, тело, все утверждения относительно реализации (например, субъективное и от первого лица) вышеизложенного основаны на опыте; Внедрение вышеуказанных принципов и концепций в качестве коммерческой организации (наемного консультанта или управляющего консультанта) в крупных финансовых учреждениях Америки и Австралии в течение 32 лет.
- Это включает в себя множество крупных заданий, исправляющих или заменяющих нестандартные или нереляционные реализации.
,
- Это включает в себя множество крупных заданий, исправляющих или заменяющих нестандартные или нереляционные реализации.
- Нулевая проблема в отношении шестой нормальной формы
Свободно доступную Белую книгу, касающуюся названия (она не определяет только Нулевую проблему), можно найти по адресу:
http://www.dcs.warwick.ac.uk/~hugh/TTM/Missing-info-without-nulls.pdf.
,
"Краткая" формулировка 6NF (значимая для тех, кто имел опыт работы с другими NF), можно найти на стр. 6
A.2 Подтверждающие доказательства
- Как указывалось в самом начале, цель этого поста - противодействие дезинформации, распространенной в этом сообществе, как услуга для сообщества.
- Доказательства, подтверждающие заявления, сделанные в отношении реализации вышеупомянутых принципов, могут быть предоставлены, если и когда будут определены конкретные заявления; и в той же степени, что неправильные заявления, опубликованные другими, на которые этот пост является ответом, также подтверждаются. Если будет бой булочек, давайте удостоверимся, что игровое поле - уровень
Вот несколько документов, на которые я могу немедленно возложить руки, чтобы начать (я нахожусь на назначении в Новой Зеландии, предоставлю больше через пару дней, имена клиентов должны быть запутаны) .
а. Большой банк
Это лучший пример, так как он был предпринят по недвусмысленным причинам в этом посте, и цели были реализованы. У них был бюджет на Sybase IQ (продукт DW), но когда мы закончили проект, отчеты были такими быстрыми, что им это не понадобилось. Торговой аналитической статистикой были мои 5NF плюс поворотные расширения, которые оказались 6NF, описанными выше. Я думаю, что на все вопросы, заданные в комментариях, даны ответы в документе, кроме:
- количество рядов:
- старая база данных неизвестна, но ее можно экстраполировать из другой статистики
- новая база данных = 20 таблиц более 100M, 4 таблицы более 10B.б. Малый финансовый институт, часть А
Часть Б - Мясо
Часть C - Схемы со ссылками
Часть D - Приложение, Аудит индексов до / после (1 строка на индекс)
Обратите внимание на четыре документа; четвертый только для тех, кто хочет проверить подробные изменения индекса. Они запускали сторонние приложения, которые нельзя было изменить, потому что у местного поставщика не было бизнеса, плюс 120% расширений, которые они могли, но не хотели менять. Мы были вызваны, потому что они обновили до новой версии Sybase, которая была намного быстрее, что сдвинуло различные пороги производительности, что вызвало большое отсутствие взаимоблокировок. Здесь мы нормализовали абсолютно все на сервере, кроме модели db, с целью (заранее гарантированной) устранения взаимоблокировок (извините, я не собираюсь объяснять это здесь: люди, которые спорят о проблеме "денормализации", будут в розовом подходит по этому поводу) . Он включал в себя инверсию "разбиения таблиц в архивную базу данных для производительности", что является предметом другого поста (да, новая отдельная таблица работала быстрее, чем две разлитые) . Это упражнение применимо и к MS SQL Server [вставить версию перезаписи].с. Йельская больница Нью-Хейвен
Это Йельская школа медицины, их учебная больница. Поддерживаю их годами. Стороннее приложение поверх Sybase. Проблема со статистикой в 80% случаев, когда они собирали снимки только в назначенные тестовые периоды, но без единой истории, поэтому нет "изображения перед", с которым можно сравнить нашу новую непротиворечивую статистику. Я не знаю ни одного другого сотрудника, который может автоматически получать внутреннюю статистику Unix и Sybase на тех же графиках. Теперь сеть является порогом (поверьте, читатель понимает, что это хорошо) .
Просто для начала, это было очищено для публикации. Больше позже. Хорошо, давайте представим доказательства того, что "денормализация" повышает производительность "и т. Д. Ваша очередь.
Длина А.3
- Я не прошу прощения за длину или сжатый характер. Люди с небольшим вниманием (без обид, в наши дни это реальность) или те, кто не знаком с реляционной технологией или терминологией, должны ссылаться на исходные тексты или сторонников этой технологии.
- По определению, это исключает Вики и любого, кто клеветает на упомянутую технологию, например, постеры, на которые этот пост является ответом. Для слона невозможно определить газель; и если они постулируют о жизни газелей, мы не должны их слушать.
Если бы я проектировал с нуля, я бы пошел с номером два. Это дает вам необходимую гибкость. Однако с номером 1, который уже существует и работает, и это довольно важно для всего вашего приложения, я бы, вероятно, с осторожностью отнесся к серьезным изменениям дизайна, не зная точно, какие запросы, хранимые процедуры, представления, пользовательские функции, отчеты, импорт и т. д. вы должны были бы изменить. Если бы это было чем-то, что я мог бы сделать с относительно низким риском (и хорошим тестированием на месте). Я мог бы пойти на переход к решению 2, иначе вы могли бы вводить новые худшие ошибки.
Ни при каких обстоятельствах я бы не использовал таблицу EAV для чего-то подобного. Они ужасны для запросов и производительности, а их гибкость сильно переоценена (спросите пользователей, предпочитают ли они добавлять новые типы 3-4 раза в год без изменения программы за счет ежедневной производительности).
Мой принцип № 1 не состоит в том, чтобы перепроектировать что-либо без причины. Так что я бы выбрал вариант 1, потому что это ваш текущий дизайн, и у него есть проверенный опыт работы.
Вместо этого потратьте время на модернизацию новых функций.
На первый взгляд, я бы выбрал вариант 2 (или 3): по возможности обобщать. Я думаю, что вариант 4 не очень реляционный и сделает ваши запросы сложными. Когда я сталкиваюсь с этим вопросом, я обычно сопоставляю эти варианты с "вариантами использования":
- Как ведет себя дизайн 2/3, когда выполняет ту или иную операцию?