Как хранить типы данных метаданных - PullRequest
2 голосов
/ 17 февраля 2012

Как хранить метаданные для описания активов? Учитывая, что я заранее не знаю, какие метаданные у меня будут.

У меня есть таблица с активами (скажем, человек), таблица с полями метаданных («имя», «возраст», «день рождения», ...) таблица со значениями метаданных, которая ссылается на таблицу полей метаданных («Джон Доу», 44, «1968-10-10», ...) и перекрестные метаданные, которые связывают поля метаданных с активами.

Моя проблема заключается в том, как мне обрабатывать различные типы данных в таблице полей метаданных. «Джон Доу» - это текст, 44 - это int, 1968-10-10 - это дата.

Сохраню ли я их в текстовом поле в моей таблице метаданных, но смогу ли я сравнить даты?

Или я могу сохранить тип данных в этой таблице и сделать 3 поля для txt, int и date. Но тогда у меня много пустых полей.

Или я создаю разные таблицы полей метаданных для каждого типа данных (например, metadatafields_txt, metadatafields_int, metadatafields_date), но тогда я не могу правильно связать таблицу метаданных.

Какая лучшая практика здесь?

ТХ

Ответы [ 2 ]

3 голосов
/ 17 февраля 2012

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

В тот момент, когда вы захотите запросить свои метаданные, держитесь подальше от хранения текстового представления, иначе вас сожгут 8<10 против '8'>'10' и друзей. В этом случае я рекомендую либо иметь таблицу метаданных с 3 полями, либо даже иметь 3 таблицы метаданных. Я подозреваю, что лучше всего было бы создать единую таблицу с 3 полями - запросы по-прежнему довольно просты и занимают много места (пустой размер - 4 байта, пустой varchar - 2 или 3 байта).

Кстати: вы можете эффективно использовать поле int для других типов данных: сохраняя метку времени unix для даты, вы сможете избежать магии UNIX_TIMESTAMP() или FROM_UNIXTIME() позже. Для строк вам может потребоваться длина (особенно если вы используете C-ish API)

1 голос
/ 17 февраля 2012

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

Третий вариант должен быть жизнеспособным - вместо внутреннего соединения с одной таблицей вы оставили бы соединение с тремя различными таблицами в вашем запросе.

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

...