Меню
Что нового?

Как правильнее: широкая таблица или длинная?

SirDimon

Новичок
Как правильнее: широкая таблица или длинная?

Планируется создание базы данных на MySQL. База будет размещаться на хостинге провайдера.

Требуется по 1000 объектов ежедневно вносить в базу 2 числа по каждому из 200 наименований.
Эти 200 наименований в принципе группируются по 10 производителям,
но количество наименований для каждого производителя разное.

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

Посоветуйте пожалуйста, как правильнее организовать структуру данных:

1 вариант: делать широченную таблицу (объект, дата, 400 полей данных )
тогда весь отчет в одну строчку

или
2 вариант: таблица поуже (объект, дата, производитель, 40 полей данных)
тогда каждый отчет будет занимать 10 записей в таблице, и для некоторых
производителей будут оставаться пустые поля

или
3 вариант: совсем узкая таблицу (объект, дата, наименование, 2 поля данных)
но тогда каждый отчет будет занимать 200 записей в таблице

Вся акция будет длиться около года, то есть количество записей
для первого варианта ~300 000,
для второго ~3 000 000,
а для третьего ~60 000 000.

Какие-то цифры огромные- это вообще как, будет работать на MySQL?

И еще вопрос:
Справится ли среднестатистический браузер с отправкой формы из 400 полей?

Заранее спасибо всем откликнувшимся.
 
длинная.
ответ этот единственно верный, даже не читая вопроса.

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

Цифры пусть тебя не пугают.

Форму можно сделать многостраничной
 
почитай что-нибудь про нормализацию

ps: думаю что вариант 3 всё таки из предложенных лучше
pps: "крокодил больше зелёный чем широкий...."
 
Таблицы конечно же будут и другие - я спрашиваю про самую большую.
У меня вот что вызывает сомнение - все равно данные будут заполняться (и наверное читаться) все 400 чисел сразу.

получается 200 INSERTов для каждого отчета?

И потом, когда будут формироваться отчеты, (например посчитать среднее значение за 3 месяца)
не будет ли тормозить выборка из таблицы, в которой 60млн записей?

Если кто-то согласится связаться со мной по ICQ 3794106, буду очень рад. А то у меня еще есть вопросы...
 
Насчет нормализации - это шутка?
И так все нормализовано.

Вопрос о том, стоит ли делать таблицу узкой и длинной, чтобы повысить производительность?
 
Чтобы повысить производительность, лучше сделать таблицу узкой и короткой.
Две узкие и короткие таблицы. В одной — производители, в другой — наименования, привязанные к производителям из первой.
 
Вообще странно слышать про 400 полей , максимум , что видел это 40 полей.

З.Ы. может в таком случае , лучше разбить 1 таблица 1 проивоводитеть, тогда это 10 таблиц в каждой не более 6 млн. записей ?
 
Пипл... ну вы хоть читайте о чем речь.....
Ясен пень, что лучше быть здоровым и богатым, чем больным и бедным.

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

А в таблице с отчетами естественно будет фигурировать ID объекта, ID наименования и т. п.

Вопрос о производительности - что лучше:
30тыс х 402 (ключ по 2 полям )
или 60млн х 5 (ключ по 3 полям)

Внутренний голос подсказывает, что много полей - это плохо.
С другой стороны - зачем писать в много строчек то, что можно написать в одну.
Вот и хотел услышать авторитетное мнение.

-~{}~ 18.04.06 16:36:

Necromant, 10 одинаковых таблиц говоришь.......

то есть еще один вариант :
10 таблиц 30тыс х 43 (ключ по 3 полям)

а если данные из них сравнивать понадобится или среднее значение вычислять?
SQL вещь умная - думаешь справится?

-~{}~ 18.04.06 16:36:

а если точнее
10 таблиц 30тыс х 42 (ключ по 2 полям)
 
SirDimon, для каждого объекта всегда все 400 полей будут заполнены?
 
vasa_c, нет, не обязательно.
Скорее всего будет заполняться около 70% полей,
но на разных объектах по разному. Заранее составить перечень наименований для объекта нельзя, он может меняться.

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

Поля из этих 400 друг от друга не зависят никак.

так что ширина таблицы на нормализованность в данном случае никак не влияет.

-~{}~ 18.04.06 17:17:

И, согласись, если мне говорят что "наименований будет наверное 189, но точно мы пока не знаем", то округлить до 200 это вполне логичный шаг.
 
поля, заполнение которых не является обязательным, и поля "про запас" - это разные вещи.
И ты, похоже, воспринимаешь термин "нормализация" в общеязыковом смысле. Типа, нормальная база =)
 
нелогичный. логично создать отдельную таблицу для наименований. каждому наименованию — одна строка. и если 189 наименований — заносить 189 строк в нее, а не 200 и не 400.
 
Вынеси в отдельную таблицу наименования, 200-400 полей это бред.

А если наменований станет более 500 ??? или 1000 ???, что новые поля добавлять ???
 
Фанат: LOL А че... наманая база...

Ну вроде уговорили делать узкую и длинную...
А про производительность что скажете? потянет на MySQL?

Я тут недавно на одном форуме читал, как хозяин жаловался, что хостер ругется из-за того, что phpBB форум слишком много запросов делает и у них от этого сервак тормозит и потеет.

А тут я с 60млн записей....
 
какая связь между количеством запросов и количеством записей?
 
все равно данные будут заполняться (и наверное читаться) все 400 чисел сразу.

получается 200 INSERTов для каждого отчета?
Нажмите для раскрытия...
MySQL позволяет вставлять сотни записей одним инсертом
 
Войдите или зарегистрируйтесь для ответа.
Сверху