Решение по дизайну для mysql

Question

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

Мой первый подход был стол так:

CREATE TABLE device_name (
id STRING(32) NOT NULL UNIQUE, 
led00 STRING(6) DEFAUTL "000000",..., 
sensor_name_status BOOL, 
sensor_name_data REAL, 
.... 
owner STRING(32) NOT NULL, 
PRIMARY KEY (id), 
FOREIGN KEY (owner) REFERENCES users(id)); 

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

Другой подход:

CREATE TABLE devices (
id STRING(32) NOT NULL UNIQUE, 
owner STRING(32) NOT NULL, 
PRIMARY KEY (id), 
FOREIGN KEY (owner) REFERENCES users(id)); 

CREATE TABLE sensors (
device_id STRING(32) NOT NULL, 
status BOOL, 
data REAL, 
type INT(3) NOT NULL, 
PRIMARY KEY (device_id,type) 
FOREIGN KEY (device_id) REFERENCES devices(id)); 

CREATE TABLE leds (
device_id STRING(32) NOT NULL, 
value STRING(6) NOT NULL, 
x INT(3) NOT NULL, 
y INT(3) NOT NULL, 
PRIMARY KEY (device_id,x,y), 
FOREIGN KEY (device_id) REFERENCES (devices)); 

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

Что вы думаете? Любая критика приветствуется :)

Answer 1

Ваш второй подход - правильное направление. Из первой строки вашего вопроса ясно: «Я хочу представить устройство, у которого есть экран с экраном, куча датчиков и некоторые другие свойства». У вас есть три разных сущности в реальном мире. Моделируйте их как три разных объекта.

Номер для улучшения. Для инициализации идентификаторов используйте автоматически увеличивающиеся первичные ключи. Я также предпочитаю называть id после имени таблицы, поэтому DeviceId является основным ключом для этого. Это означает, что любое соединение является «очевидным», потому что поля объединения называются одинаковыми или очень похожими.

Кроме того, я думаю, вам нужны дополнительные таблицы для Sensors и, возможно, LED. То есть, информация type должна храниться в другой таблице.

Вот мое предложение:

CREATE TABLE Devices (
    DeviceID int not nullauto_increment primary key 
    Name varchar(32) NOT NULL UNIQUE, 
    Owner_UserId int NOT NULL, 
    FOREIGN KEY (Owner_UserId) REFERENCES users(Userid) 
); 

create table Sensors (
    SensorId int not null auto_increment primary key, 
    Type int, 
    Name varchar(255) 
); 

CREATE TABLE sensors (
    DeviceID int NOT NULL, 
    SensorID int not null, 
    status BOOL, 
    data REAL, 
    primary key (DeviceID, SensorId) 
    foreign key (DeviceID) REFERENCES devices(DeviceID), 
    foreign key (SensorId) REFERENCES sensors(SensorID), 
); 

CREATE TABLE leds (
    DeviceID int not null, 
    value varchar(6) NOT NULL, 
    x INT(3) NOT NULL, 
    y INT(3) NOT NULL, 
    PRIMARY KEY (DeviceID, x, y), 
    FOREIGN KEY (DeviceID) REFERENCES devices(DeviceID) 
); 

В общем, при создании таблиц, я также добавить два или три столбца по умолчанию в конце:

CreatedAt . . . the date/time when created (a timestamp column in MySQL) 
CreatedBy . . . who created the column 
CreatedOn . . . The server where the machine was created (if the system is going to span servers)