Звучит так, как будто вы рассматриваете динамическую базу данных TM .
По-моему, это неправильный путь; в основном по причинам, которые вы перечислили.
Второй вариант:
Ваша таблица attribute должна хранить все в виде строки, а затем, как вы говорите, отобразить ее обратно. Это излишне усложняет ситуацию и означает, что всякий раз, когда вы выбираете из базы данных или проводите сравнение, вы должны конвертировать каждое значение обратно в его исходный тип данных, используя вашу таблицу attribute_data_types. Или вы можете выбрать другой путь - один столбец каждого типа данных и каким-то образом динамически выбирать, какой столбец обновлять или выбирать в зависимости от используемого типа данных.
Если вы пойдете по этому маршруту, я могу предложить вам добавить тип данных в эту таблицу, применяя проверочное ограничение вместо attribute_data_types. Количество типов данных не будет меняться часто, и вы прекратите добавление недопустимых типов в ваш набор данных с помощью этого типа ограничения.
Вот предыдущий вопрос о проблемах, с которыми вы можете столкнуться с динамической базой данных .
Первый вариант:
Как правило, я буду хранить данные на том же уровне, предпочтительно в той же таблице, что и уникальный идентификатор, связанный с ним. Таким образом, если у вас есть атрибут, который специально привязан к пользователю, я бы взял удар и добавил столбец в таблицу users. Вы не указываете, сколько атрибутов вы хотите, чтобы пользователь имел, поэтому в долгосрочной перспективе это может стать нелепым, но вам не придется беспокоиться об этом в течение длительного времени.
Если вас беспокоит добавление дополнительных столбцов, вы можете вначале сделать ужасный хак и добавить 20 дополнительных столбцов new_attribute1, ..., new_attribute20, а затем переименовать их по мере использования.
Третий вариант:
Вы упоминаете, что рассматриваете возможность реализации пользовательских типов ... есть некоторые данные, которые вы хотите сохранить независимо от пользователя, даты рождения, имени и т. Д., Которые не исчезнут.
Хотя мне не так нравится, как хранить все в таблице user, вы можете сохранить все свои статические атрибуты (дата рождения и т. Д.) В таблице user, а затем создать вторую таблицу user_attributes, уникально в user_id для хранения менее общих, к которым вам нужно будет присоединиться только при выполнении менее общих запросов. Это уменьшит размер таблицы пользователей.
В конце дня, и, как прокомментировал Ричард А , правильного пути нет; ты должен делать то, что тебе подходит. Если это возможно, сначала проведите несколько тестов и посмотрите, что лучше всего подойдет для вашей ситуации.
На заметке никогда не сохраняйте возраст, как вы упомянули. Он меняется каждый год, и вы должны постоянно обновлять свою таблицу; просто сохраняйте данные о рождении и выполняйте вычисления при получении данных.