#3: Какой вариант структуры Mysql базы будет надёжнее.

Айв, 385 просмотров

Сразу предупреждаю, я не профи в СуБД.
Структуры приведены в качестве примера для понимания. Не надо искать в них ошибки.
Есть таблица user. В таблице user есть стандартные поля:
user_id int(6) K auto
user_name varchar(32) U
user_password varchar(64)
Работаю над системой и встал вопрос о дальнейшей структуре. Через систему управления администратор может добавить дополнительные атрибуты. То-есть к примеру чтобы можно было добавить для пользователя Ф.И.О.
В голове только 2 варианта структуры.
а::
Создать таблицу attr где будут содержатся список атрибутов дополнительных.
Создать таблицу attr_data со структурой: attr_id, value, user_id куда будут записываться нужные данные.
б::
При создании нового атрибута просто добавлять в таблице user новое поле. К примеру fio, passport.
Конечная структура будет в данном случае:
user_id int(6) K auto
user_name varchar(32) U
user_password varchar(64)
fio [тип_значения]
passport [тип_значения]

С одной стороны второй вариант проще. Особенно если учесть, что при выводе списка пользователя отсортировать будет проще. Чем ползать по нескольким таблицам и строить ассоциированные массивы.
С другой стороны есть небольшое опасение на предмет надёжности структуры таблицы. Атрибутов будет много и некоторые из них будут по типу TEXT.

Вопрос заключается в том, какой вариант лучше с точки зрения надёжности базы. Учитывая, что атрибутов на моей копии системы уже больше 40.
Если есть другой вариант - буду рад его услышать.
Тип таблиц MyISAM

Заранее благодарю.

Примечание:
Интенсивность обращения довольно большая. Не просто чтение данных, но постоянное обновление значений. Атрибуты так таковые будут использоваться не только для администраторов, но и для записи других параметров.

Ответы:

whyte624

Могу сказать, что таблицы в mySql ограничены в ширину. Я однажды столкнулся с проблемой, когда в таблице было n столбцов типа varchar(255) и больше добавлять столбцы (n+1) было нельзя. Точное значение n не помню, а рыть документацию лень.

Web

Что понимается под термином "надежность"? Какое основное назначение таблицы (сколько данных, интенсивность обращений к ним)?

Web

Если интенсивность, действительно очень высокая, а данных мало, то лучше использовать одну таблицу.

Без имени

Первый вариант предпочтительней

Японский Городовой

1. Сделать одну нормальную таблицу с нужными полями. Не слушать идиотские сказки про ограничение в ширину (Разумный размер таблицы никогда не выйдет ни за какие ограничения).Не делать из простой базы данных конструктор "сделай-сам-все-что-взбредет в голову". пользователи - дебилы еще хуже разработчиков. Они или не будут ничего добавлять вообще, или надобавляют такого, что поставят систему раком.
2. Хорошо подумать, действительно ли нужна такая структура, или это исполнитель не понял заказчика или сам нафантазировал для красоты.
2. Если действительно нужно это добавление, то искать решение, МАКСИМАЛЬНО ПРИБЛИЖЕННОЕ К РЕАЛЬНОСТИ. Вариантов решения задачи может быть много, и совсем не обязательно это будут описанные выше. Если хочешь получить реальный ответ, надо задавать реальный вопрос.

Японский Городовой

Выше я не совсем точно выразил свою мысль.
1. Для полей, про которые заранее известно, что они нужны - забить их в основную таблицу.
2. Для оставшихся - подумать. Хорошо подумать - нужно ли вообще их добавление. что это за возможно возникающие в будущем параметры? какова вероятность их появления? имеет ли смысл ради них огород городить? По результатам размышлений принять решение - делать ли вообще, если делать - то как.
3. Если пришли к выводу, что да, то искать решение сходной практической проблемы. А не абстрактной "как сделать сферическому коню в вакууме добавление неизвестного количества сферических ног".

Без имени

Городовой

16 лет назад

RPI.su - самая большая русскоязычная база вопросов и ответов. Наш проект был реализован как продолжение популярного сервиса otvety.google.ru, который был закрыт и удален 30 апреля 2015 года. Мы решили воскресить полезный сервис Ответы Гугл, чтобы любой человек смог публично узнать ответ на свой вопрос у интернет сообщества.

Все вопросы, добавленные на сайт ответов Google, мы скопировали и сохранили здесь. Имена старых пользователей также отображены в том виде, в котором они существовали ранее. Только нужно заново пройти регистрацию, чтобы иметь возможность задавать вопросы, или отвечать другим.

Чтобы связаться с нами по любому вопросу О САЙТЕ (реклама, сотрудничество, отзыв о сервисе), пишите на почту [email protected]. Только все общие вопросы размещайте на сайте, на них ответ по почте не предоставляется.