mysql: наиболее эффективный способ хранения параметров с неизвестным типом (string / int) в БД - PullRequest
Новая
       1

mysql: наиболее эффективный способ хранения параметров с неизвестным типом (string / int) в БД

0 голосов
/ 21 декабря 2010

У меня есть система обмена сообщениями, которая содержит шаблоны по умолчанию.например:

you won X coins

friend X wants to share the url Y with you

, поэтому число параметров варьируется в каждом типе сообщения / шаблона.

Я думал о 4Типы решений для решения проблемы:

  1. создание таблицы параметров и представление каждого типа параметра в виде строки.проблема здесь в том, что user_ids будут представлены в виде строк, поэтому, вероятно, соединения будут медленнее.e

  2. создание таблицы параметров, в которой каждая строка содержит следующее логическое значение, указывающее, является ли параметр целым или строковым, и 2 других столбца: один тип текста, а другой тип INT.поэтому здесь мы теряем пространство, потому что всякий раз, когда мы используем параметр int, строка содержит неиспользуемую строковую ячейку.

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

  4. создание двух разных таблиц для каждого времени параметров: messages_param_int и messages_param_string и таблица, которая содержит каждый параметр в уведомлении для соответствующей таблицы.это решение может быть медленнее, чем решение 2, потому что мне нужно проверить, из какой таблицы сначала получить информацию.

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

Я не эксперт по MySQL, поэтому заключение каждого метода может быть неправильным.

Любая информация будет принята с благодарностью.

спасибо!

1 Ответ

1 голос
/ 21 декабря 2010

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

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

В вашем случае, я бы просто выбрал # 1 или # 2 и подумал бы о продвижении важных свойств, если возникнет такая необходимость.

...