Форум MySQL

Плиз, подскажите как эффективнее:
Есть анкета на 150-200 полей, данные должны быть в БД.
Варианты хранения информации
1) все анкетные данные в одну таблицу (получается 150-200 полей, зато запросы только к одной таблице);
2) делим анкетные данные на части и пишем в разные таблицы, полей по 10-20... зато таблиц 10-20...

Правильно ли я считаю, что первый вариант лучше?

Нет не правильно, конечно. Спрашивается тогда зачем выдумали реляционные БД - в основе которых стоит двумерный массив и данные размещаются в соответствии с логикой их размещения.

не понял я вас.
одна таблица в которой 150 полей, сколько человек заполнило анкету, только и записей в таблице. Разве такая таблица не подходит под требования реляционной БД?

Рекомендую создать 3 таблицы.
1. Список анкет (анкетируемых)
2. Список полей анкеты.
3. Значения полей анкеты и индетификатор анкеты.

на мой взгляд это ещё больше загрузит сервер....

чем меньше запросов к БД, тем выше производительность...
мучаюсь с вопросом, что быстрее:
1) 3 запроса к 4-ём таблицам по 50 полей
или
2) 1 запрос к 1 таблице с 200 полями...

просьба не путать "поле" и "запись" БД.

Нет, конечно же - сущность РСУБД как раз-таки в том и состоит чтобы нормализовать таблицы.

если все данные (около 200) относятся к одному айдишнику или имени, есть смысл разбивать таблицу на несколько?
т.е. была одна таблица: id=1, поле1="", поле2="", ... поле200="".
а стало 10 таблиц с записями: id=1, поле1="", поле2="", ... поле20="".
нет же смысла это делать, если данные если и используются, то только все вместе?

Скорее всего 200!!! полей в анкете могут меняться, по необходимости удалаяться или добавляться. При жесткой структуре (200 полей в таблице) нужно будет менять таблицу, что не всегда удобно и, даже, возможно (программа работает у клиента). Существенно легче добавить или удалить поле, как значение в таблице. Это могут делать даже пользователи не имеющие понятия о БД.

по поводу добавления/удаления полей думал, как раз таким способом, но это чуток позже...
в данный момент хотелось узнать ответ именно на тот вопрос, который был задан :)

Я никогда не поверю, что таблица, содержащая 200! столбцов имеет право на жизнь. Я такого честно не встречал в своей практике. Тогда объясните что вы собирайтесьв в ней хранить. Ну есть ip дальше что - какая сопутствующая инфа будет хранится с ним ?
Ну могу предположить, например такой показатель как динамический ip или статический. Ну так и храните тип ip в другой таблице. Это делается именно так. Благодаря этому существенно уменьшится сопровождение вашей БД. И в определенной степени обеспечит ограничение целостности ваших данных.

-

>по поводу добавления/удаления полей думал, как раз таким способом, но это чуток позже...
>в данный момент хотелось узнать ответ именно на тот вопрос, который был задан :)
Это полностью взимоствязанные вопросы. Создавая структуру БД (таблиц) нужно думать, как с ними в дальнейшем Вы будете работать.
Как вы яхту назовете ...