Я пытаюсь решить, как сохранить некоторые данные в моей базе данных. (SQLite) Допустим, у нас есть 2 таблицы: атрибут и тип

Тип таблицы более или менее похож на enum, он хранит все типы, существующие в моей модели (например, Integer, Real, Alphanumeric)

Атрибут таблицы содержит атрибуты, запись выглядит так:

Attribute :
id : its id
name : name of the attribute
value : ??? (the main question here)
type : foreign key to table type

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

Я рассмотрел до сих пор 3 решения:

Решение 1. Поле «значение» атрибута имеет тип String, и я программно преобразую его в соответствующий тип

Решение 2: я создаю больше полей «значения», таких как: intValue, realValue и alphanValue, и помещаю NULL в несущественные поля в зависимости от типа

Решение 3: я создаю еще 3 таблицы, IntValue, RealValue и AlphaNValue с внешним ключом для соответствующего атрибута.

Я хочу знать, какое решение лучше с точки зрения производительности и согласованности, или есть ли другое подходящее решение, о котором я не думал.

Большое спасибо

0
SivaDashq 24 Апр 2017 в 11:49

2 ответа

Лучший ответ

Ваш вопрос помечен MySQL, но вы говорите, что он о SQLite - пожалуйста, пометьте правильно, это помогает другим!

Похоже, вы реализуете Entity-Attribute-Value как решение. Существует множество обсуждений этой концепции - этот является одним из самых полезных ,

Одна из распространенных критических замечаний, высказанных в отношении EAV, - это как раз тот вопрос, который вы задаете - хранить данные в соответствующих типах данных сложно.

Поэтому, если вы этим занимаетесь, обратите внимание на альтернативы EAV - обычно «гибкость» имеет столько недостатков, что она того не стоит. Особенно в стесненных условиях, таких как SQLLite.

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

0
Community 23 Май 2017 в 12:25

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

Если есть причина сделать это менее простым, мне не хватает причины. Может быть, объяснить, почему вы пошли бы более сложным путем в вашем случае.

0
vv01f 24 Апр 2017 в 09:05
43583593