Mysql размеры полей по метаданным

Question

Я хочу, чтобы создать таблицу, которая будет содержать динамические данные, он может быть в виде даты, логическое значение или текст статьи

, например:

meta_key = " IsActive» meta_valu = "1"

или

meta_key = "theDate" meta_value = "сб 23 июля 2005 2:16:57"

или

meta_key = «Описание» meta_value = «это описание и этот текст может пойти дальше и дальше, так что мне нужно длинное поле»

Вопрос в том, какой тип поля meta_value должно быть в порядке чтобы не раздувать DB слишком много для каждого «1», вставленной, какие поля являются динамичными и будет потреблять только пространство своей собственной длины

надеюсь, что было ясно ...

Answer 1

Вы, вероятно, хотите VARCHAR field type.

В отличие от CHAR, значения VARCHAR сохраняются в виде однобайтового или двухбайтового префикса длины плюс данные.

Answer 2

Надеется, что это помогает:

datatype=Text 

Answer 3

Я хотел бы использовать только неструктурированную модель данных, например, как вы предлагаете, если вы храните неструктурированные данные или документы (например, FriendFeed).

Альтернативных мысли хранения

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

Опции SQL

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

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

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

Следующие 2 вариант обеспечивает решение обе эти проблемы ...

XML - XML ​​типа данных

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

http://msdn.microsoft.com/en-us/library/ms189887.aspx

или JSON - NVARCHAR (макс) тип данных

Если вам необходимо вернуть эти данные для отображения на веб-странице или использовать в Javascript, затем хранить в формате JSON будет проще работать с. Вы можете легко загрузить его в объектную модель, с которой можно напрямую работать и манипулировать. Недостатком является то, что сложные поиски по данным будут очень медленными по сравнению с XPATH (итерация по всем объектам, поиск которых соответствует).

Если вы сохраняете данные с других языков или странные символы, переходите к nvarchar (версия Unicode). В противном случае варчар был бы наиболее эффективным.

Answer 4

Используются ли они в качестве временных таблиц или таблиц в реальном времени?

Вот идея, которую я еще не видел, но МОЖЕТ работать на вас, если вы в первую очередь беспокоитесь о взрыве размера, но не заботитесь о том, чтобы программа выполняла небольшую дополнительную работу. Тем не менее, я считаю, что наилучшей практикой является создание этих мета-ключей с полями в их собственной таблице (например, OrderDate), а затем вы можете иметь описания, даты и т. Д. Таблицу БД можно сделать для многих головных болей.

Создание мета-таблицы, используя эту идею:

MetaID MetaKey MetaVarchar (255) метатекстовых Metadate

VARCHAR, текст и дата может быть пустым.

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

Answer 5

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

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

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

Вот лучшее объяснение типа BLOB данных: http://dev.mysql.com/doc/refman/5.0/en/blob.html