Предложение структуры таблицы MySQL?

Question

эта таблица хороша для mysql? Я хотел сделать это гибким в будущем для этого типа хранения данных. С этой структурой таблицы вы не можете использовать ПЕРВИЧНЫЙ КЛЮЧ, а индекс ...

Следует ли изменить формат таблицы, чтобы иметь заголовки - Первичный ключ, Ширина, Длина, Пространство, Связь ...

ID_NUM  Param   Value
1   Width   5e-081
1   Length  12
1   Space   5e-084
1   Coupling    1.511
1   Metal Layer     M3-0
2   Width   5e-082
2   Length  1.38e-061
2   Space   5e-081
2   Coupling    1.5
2   Metal Layer     M310

Answer 1

Нет, это плохой дизайн для реляционной базы данных.Это пример дизайна Entity-Attribute-Value .Это гибкий инструмент, но он нарушает большинство правил того, что значит быть реляционной базой данных.

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

В частности, некоторые из проблем с EAV включают:

• Вы не знаете, какие атрибуты существуют для любого заданного ID_NUM, не запрашивая их.
• Выне может сделать какой-либо атрибут обязательным, эквивалент NOT NULL.
• Нельзя использовать ограничения базы данных.
• Нельзя использовать типы данных SQL;столбец value должен быть длинным VARCHAR.
• В частности, в MySQL каждый VARCHAR хранится на собственной странице данных, поэтому это очень расточительно.

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

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

Я написал больше о EAV в своей презентации Практические объектно-ориентированные модели в SQL и в своем блоге EAV FAIL и в моей книге Антипаттерны SQL: предотвращение ловушек программирования баз данных .

Answer 2

То, что вы предлагаете, называется EAV model (Entity–Attribute–Value)

У него есть несколько недостатков, таких как серьезные трудности в применении ограничений ссылочной целостности. Кроме того, запросы, с которыми вам придется столкнуться, будут немного сложнее, чем с нормализованной таблицей в качестве второго предложения (таблица со столбцами: Primary Key, Width, Length, Space, Coupling, etc).

Итак, для простого проекта не используйте модель EAV.

Если ваши планы на более сложный проект и вы хотите максимальной гибкости, также не используйте EAV. Вы должны взглянуть на 6NF (6th Normal Form), который еще сложнее реализовать и, конечно, не является легкой задачей в MySQL. Но если вам это удастся, вы получите оба товара: гибкость и нормализацию до самого высокого уровня (некоторые люди называют « EAV » как « 6NF сделано неправильно »).

Answer 3

Несколько вещей, которые следует учитывать здесь:

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

Повторяется столбец Param, и для его нормализации следует обратиться к примеру MGA.

В-третьих, столбец «Металлический слой» - это строка, а не значение с плавающей запятой, как у других.

Поэтому лучше всего использовать таблицу с таким определением:

create table yourTable(
  ID int primary key,
  ParamId int not null,
  Width float,
  Length float,
  Space float,
  Coupling float,
  Metal_layer varchar(20),
  Foreign key(ParamID) references Param(ID),
  Value varchar(20)
)
create table Param(
  ID int primary key,
  Name varchar(20)
)

Answer 4

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

С положительной стороны: он легко расширяется без изменений в структуре базы данных и в некоторых отношениях абстрагирует детали хранения данных.

С отрицательной стороны: вам нужно взглянуть на все повседневные вещи, хранящие поля по столбцам, которые автоматически предоставляют вам в СУБД: простые внутренние / внешние объединения, одно предложение вставки / обновления, уникальность, внешние ключи и другие ограничения уровня БД проверка, простая фильтрация и упорядочение результатов поиска.

Рассмотрим в вашей архитектуре запрос на возврат всех элементов с MetalLayer = X и шириной между y и z - результаты отсортированы по длинам связи. Этот запрос гораздо сложнее создать, а СУБД выполнить намного сложнее, чем использовать столбцы для хранения определенных полей.

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

Answer 5

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

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

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

CREATE TABLE testtest (
  ID    INT  NOT NULL  PRIMARY KEY  AUTO_INCREMENT,
  Name  VARCHAR(100)  NOT NULL,
  value number  NOT NULL
/*add other fields here*/
);

CREATE TABLE testtest (
  name  VARCHAR(100)  NOT NULL,
  value int  NOT NULL,
/*add other fields here*/
  primary key(name,value)
);

В примере создания этой таблицы выражены 2 вышеупомянутых параметра..