Схема базы данных проекта с полями слияния, которые содержат разные типы значений [duplicate]

Question

Схема базы данных проекта с полями слияния, которые содержат разные типы значений [duplicate]

Я запускаю Apache на Ubuntu, и моя проблема в том, что файл /etc/apache2/mods-available/php5.conf отсутствовал:

<FilesMatch ".+\.ph(p[345]?|t|tml)$">
    SetHandler application/x-httpd-php
</FilesMatch>

Я добавил его обратно, а php правильно обрабатывал файлы php.

111

mysql sql database database-design database-schema

задан Air 4 November 2014 в 01:16

4 ответа

5

ответ дан JD Isaacks 20 August 2018 в 22:45

@StoneHeart

Я бы пошел сюда с EAV и MVC полностью.

@Bill Karvin

Вот некоторые из недостатков EAV:
No way to make a column mandatory (equivalent of NOT NULL).
No way to use SQL data types to validate entries.
No way to ensure that attribute names are spelled consistently.
No way to put a foreign key on the values of any given attribute, e.g.
для таблицы поиска.

Все те вещи, которые вы упомянули здесь:

проверка данных

атрибуты имен проверка орфографии

обязательные столбцы / поля

обработка уничтожения зависимых атрибутов

по-моему

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

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

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

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

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

Если вы все равно будете обеспокоены эксплуатацией операций, выполняемых приложением, вы всегда можете использовать Erlang, C ++, Go Language для предварительной обработки данных, а затем просто обработайте оптимизированные данные в главном приложении.

13

ответ дан Pawel Barcik 20 August 2018 в 22:45

1

you can always use Erlang, C++, Go Language to pre-process the data Что вы имели в виду? Вместо DB, используйте Go lang? Не могли бы вы рассказать об этом? – Green 6 November 2016 в 09:15
2

Я абсолютно согласен. EAV - это способ продвижения, особенно если вам нужен уровень гибкости, который позволит вам добавлять новые виды продуктов и параметров без изменений схемы дБ, я имею в виду жить в производстве через ваше приложение. Был там, сделал это. Работал для меня. О медленных запросах ... кто-нибудь из нас когда-либо слышал о кешах? ;) – pawel.kalisz 1 December 2016 в 08:35
3

@Green Я отредактировал последний абзац, чтобы сделать его более понятным, но речь идет о передаче ваших необработанных данных EAV в процесс на языке, который может обрабатывать преобразования данных, поиск в древовидной структуре или любую базовую карту, в памяти эффективным способом. Специфика здесь будет зависеть от того, что нужно оптимизировать – Pawel Barcik 7 February 2017 в 17:44

У вас может быть таблица Product и отдельная таблица ProductAdditionInfo с тремя столбцами: идентификатор продукта, дополнительное информационное имя, дополнительная информация. Если цвет используется многими, но не всеми видами Продуктов, вы можете иметь его столбцом с нулевым значением в таблице Product или просто поместить его в ProductAdditionalInfo.

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

Steve Yegge называет это шаблоном Properties и написал длинный пост об использовании его.

3

ответ дан RossFabricant 20 August 2018 в 22:45

1

Шаблон свойств представляет собой значение Entity-Attribute-Value другим именем. Он широко используется, но его хранение в реляционной базе данных нарушает правила нормализации. – Bill Karwin 30 March 2009 в 03:44
2

Если честно, когда я прочитал описание EAV в ответе @Bills, я не совсем понял, что он объяснял. Но когда вы сказали 3 columns: product ID, additional info name, additional info value, я понял эту концепцию. И я на самом деле сделал это раньше, и столкнулся с проблемами. Однако на данный момент я не помню, какими были эти проблемы. – JD Isaacks 16 September 2010 в 19:55
3

@JDIsaacks В этом шаблоне общая проблема заключается в том, что мы не знаем, сколько JOINs нам нужно для извлечения всех атрибутов. – Omid 3 December 2013 в 10:00

Другие вопросы по тегам:

mysql sql database database-design database-schema

Похожие вопросы:

you can always use Erlang, C++, Go Language to pre-process the data Что вы имели в виду? Вместо DB, используйте Go lang? Не могли бы вы рассказать об этом? — Green, 6 November 2016 в 09:15
Я абсолютно согласен. EAV - это способ продвижения, особенно если вам нужен уровень гибкости, который позволит вам добавлять новые виды продуктов и параметров без изменений схемы дБ, я имею в виду жить в производстве через ваше приложение. Был там, сделал это. Работал для меня. О медленных запросах ... кто-нибудь из нас когда-либо слышал о кешах? ;) — pawel.kalisz, 1 December 2016 в 08:35
@Green Я отредактировал последний абзац, чтобы сделать его более понятным, но речь идет о передаче ваших необработанных данных EAV в процесс на языке, который может обрабатывать преобразования данных, поиск в древовидной структуре или любую базовую карту, в памяти эффективным способом. Специфика здесь будет зависеть от того, что нужно оптимизировать — Pawel Barcik, 7 February 2017 в 17:44
Шаблон свойств представляет собой значение Entity-Attribute-Value другим именем. Он широко используется, но его хранение в реляционной базе данных нарушает правила нормализации. — Bill Karwin, 30 March 2009 в 03:44
Если честно, когда я прочитал описание EAV в ответе @Bills, я не совсем понял, что он объяснял. Но когда вы сказали 3 columns: product ID, additional info name, additional info value, я понял эту концепцию. И я на самом деле сделал это раньше, и столкнулся с проблемами. Однако на данный момент я не помню, какими были эти проблемы. — JD Isaacks, 16 September 2010 в 19:55
@JDIsaacks В этом шаблоне общая проблема заключается в том, что мы не знаем, сколько JOINs нам нужно для извлечения всех атрибутов. — Omid, 3 December 2013 в 10:00

score 193 · Accepted Answer

У вас есть по крайней мере эти пять вариантов моделирования иерархии типов, которую вы описываете:

Наследование отдельных таблиц : одна таблица для всех типов продуктов, с достаточным количеством столбцов для хранить все атрибуты всех типов. Это означает много столбцов, большинство из которых имеют NULL в любой заданной строке.
Наследование классов таблицы : одна таблица для продуктов, ко всем типам продукции. Затем одна таблица для каждого типа продукта, сохраняющая атрибуты, специфичные для этого типа продукта.
Наследование бетонных таблиц : нет таблицы для общих атрибутов товаров. Вместо этого одна таблица для каждого типа продукта, сохраняющая как общие атрибуты продукта, так и атрибуты продукта.
Сериализованная LOB : одна таблица для продуктов, сохраняющая атрибуты, общие для всех типов продуктов. В одном дополнительном столбце хранится BLOB полуструктурированных данных в формате XML, YAML, JSON или в другом формате. Этот BLOB позволяет сохранять атрибуты, специфичные для каждого типа продукта. Вы можете использовать причудливые шаблоны проектирования, чтобы описать это, например, «Фасад» и «Memento». Но независимо от того, у вас есть blob атрибутов, которые не могут быть легко запрошены в SQL; вы должны вернуть весь blob обратно в приложение и отсортировать его там.
Entity-Attribute-Value : одна таблица для продуктов и одна таблица, которая сводит атрибуты к строкам , вместо столбцов. EAV не является корректным проектом в отношении реляционной парадигмы, но многие люди его используют. Это «Шаблон свойств», упомянутый другим ответом. Другие вопросы с тегом eav на StackOverflow для некоторых ошибок.

Я написал об этом больше в презентации, Расширяемое моделирование данных .

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

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

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

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

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

я искал это с давних времен ... вариант 4,5 кажется хорошим ... — Himalaya Garg, 29 September 2013 в 16:49
@HimalayaGarg Option & quot; 4.5 & quot; на самом деле это противоположность всему делу Билла. — user3308043, 29 August 2014 в 20:28
В отличие от MySQL, SQL Server имеет обширную поддержку XML, XPath и XQuery. Поэтому для пользователей SQL Server лучшим вариантом будет хранение дополнительных атрибутов в столбце типа XML (вариант 4). Таким образом, вам не нужно «возвращать весь кадр обратно в приложение и сортировать его там». Вы даже можете создавать индексы в столбцах XML в SQL Server. — Delphi.Boy, 2 October 2014 в 07:48
@ Delphi.Boy, отличный совет! Oracle также поддерживает индексирование XML . IBM DB2 также поддерживает индексирование XML . — Bill Karwin, 2 October 2014 в 16:25
Я предпочитаю Serialized LOB для моего случая. Но подходит ли он для ОРМ? Я использую EF. — Mahmood Jenami, 22 March 2015 в 15:10