|
|
Задавайте вопросы, мы ответим
Вы не зашли.
Здраствуйте
У меня к вам такой вопрос.....
какая структура таблиц быстрая....
когда у таблицы много столбцов или много строк....
например....
table_1
id | exam_no | math_answ | math_true | math_false | chem_answ | chem_true | chem_false | ...
--+---------+------------+-----------+------------+------------+-----------+------------+...
1 | 10 | ABCDE | 1 | 4 | AABBC | 4 | 1 |...
2 | 11 | AAACD | 3 | 2 |CDDAB | 3 | 2 |...
table_2
id |exam_no | lesson | answer | true | false
---+--------+--------+-------+-----+--------
1 |10 | math | ABCDE | 1 | 4
2 |10 | chem | AABBC | 4 | 1
3 |11 | math | AAACD | 3 | 2
4 |11 | chem | CDDAB | 3 | 2
каждая таблица имеет более 1000 строк....
И так какая таблица оптимальная?
с какой таблицей работать будет удобнее?
И какая таблица будет быстрая?
Неактивен
А чтобы вы ответили на вопрос: "Красный или большой сферический конь в вакууме будет удобней?" 
В вашем случае выбор структуры зависит от того какие запросы вы собираетесь делать к таблице.
Неактивен
Но с точки зрения нормализации второй вариант лучше
Неактивен
ОК
но как задать запросы когда количество строк более 100.000 и сервер работал нормально
Неактивен
Так же, как и всегда?
Неактивен
И все-таки сори за некропостинг, но очень хотелось бы узнать.
У меня чем-то похожая ситуация.
Имеется таблица, в которой хранятся определенные "параметры" (их количество может меться в зависимости от предпочтений будущего юзера). Так вот некоторые из них такие, для которых предполагается несколько значений одного параметра к строке таблицы.
Я вижу три варианта решения:
1. для каждого из таких параметров создавать отдельную таблицу в которой будет два стобца - id из главной таблицы и значение параметра.
минус этого варианта - куча таблиц (так как таких полей может быть довольно много) и последующий гемор их выборки
2. основную таблицу создать с минимум столбцов и вместе с ней создать вторую таблицу {id из главной страницы, название параметра, значение параметра}. таким образом все параметры, включая те, которые имеют по несколько значений будут находится в одной таблице.
3. сделать что-то среднее между 1 и 2 вариантом. в главной таблице оставить те параметры, у которых может быть только одно значение на строку. а те параметры у которых может быть несколько значений на строку вынести в отдельную таблицу (то есть одна таблица для всех параметров такого типа, а не как в первом случае на каждый параметр по таблице)
в общем мне больше всего нравятся 2 и 3 варианты, правда третий менее универсален, так как нужно делить параметры на две группы
но тут возникает вопрос, а если у меня допустим будет в главной таблице где-то 5 000 или вообще 10 000 строк, а в таблицах с параметрами соответственно раз так в 10-20 больше? какой вариант будет работать быстрее?
1 (основная таблица плюс до 10 дополнительных таблиц)
2 (основная таблица + одна дополнительная с 20 записями на каждую запись из основной таблицы)
3 (основная таблица + 1 таблица с 10 записями на каждую запись основной)
или в целом я особых изменений не замечу? просто у меня маловато опыта работы с бд, особенно с огромными. я знаю, что по началу любой из способов будет работать чудесно, но может быть такое, что один из них в будущем будет вообще не юзабельным. так вот если один из них плохой, укажите мне и я больше никогда не буду так делать.
Неактивен
Если значения примитивные (т.е. информация о них - это только их набор, никаких дополнительных параметров хранить не нужно), есть еще четвертый вариант - использование типа данных SET: http://dev.mysql.com/doc/refman/5.5/en/set.html
Неактивен
о, за SET спасибо. это пригодится. Но часть параметров не будет иметь четких значений, так что придется еще использовать и те варианты о которых я писал...
в общем при разработке структуры бд я должен стремится к уменьшению возможного количества строк в таблице (за счет использования доп. таблиц или колонок), я верно понимаю?
Неактивен
Ну, в целом, нужно стремиться к нормализации таблиц (т.е. п. 1 - когда куча таблиц).
Насколько решение будет успешным - зависит от конкретных запросов, это уже надо проверять.
Если окажется, что много ресурсов тратится на JOIN (когда их много, например), тогда уже нужно проводить частичную денормализацию (т.е. дублировать данные, записывая их в основную таблицу в виде результата каких-то групповых операций).
В общем случае работать с максимально нормализованными таблицами удобнее.
Неактивен
ок. большое спасибо за помощь
Неактивен
