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

[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 полей?

Заранее спасибо всем откликнувшимся.

 

[Фанат]

длинная.
ответ этот единственно верный, даже не читая вопроса.

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

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

Форму можно сделать многостраничной

 

[zerkms]

почитай что-нибудь про нормализацию

ps: думаю что вариант 3 всё таки из предложенных лучше
pps: "крокодил больше зелёный чем широкий...."

 

[SirDimon]

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

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

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

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

 

[Фанат]

так ты задвай, не стесняйся.

 

[SirDimon]

Насчет нормализации - это шутка?
И так все нормализовано.

Вопрос о том, стоит ли делать таблицу узкой и длинной, чтобы повысить производительность?

 

[vasa_c]

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

 

[Necromant]

Вообще странно слышать про 400 полей , максимум , что видел это 40 полей.

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

 

[SirDimon]

Пипл... ну вы хоть читайте о чем речь.....
Ясен пень, что лучше быть здоровым и богатым, чем больным и бедным.

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

А в таблице с отчетами естественно будет фигурировать 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 полям)

 

[vasa_c]

SirDimon, для каждого объекта всегда все 400 полей будут заполнены?

 

[SirDimon]

vasa_c, нет, не обязательно.
Скорее всего будет заполняться около 70% полей,
но на разных объектах по разному. Заранее составить перечень наименований для объекта нельзя, он может меняться.

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

 

[Фанат]

и теперь ты нам рассказываешь, что у тебя база нормализована? С небольшим запасиком?

 

[SirDimon]

А что тут ненормализованного? Практически во всех базах есть поля, заполнение которых не является обязательным.

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

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

-~{}~ 18.04.06 17:17:

И, согласись, если мне говорят что "наименований будет наверное 189, но точно мы пока не знаем", то округлить до 200 это вполне логичный шаг.

 

[Фанат]

поля, заполнение которых не является обязательным, и поля "про запас" - это разные вещи.
И ты, похоже, воспринимаешь термин "нормализация" в общеязыковом смысле. Типа, нормальная база =)

 

[vasa_c]

нелогичный. логично создать отдельную таблицу для наименований. каждому наименованию — одна строка. и если 189 наименований — заносить 189 строк в нее, а не 200 и не 400.

 

[Necromant]

Вынеси в отдельную таблицу наименования, 200-400 полей это бред.

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

 

[SirDimon]

Фанат: LOL А че... наманая база...

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

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

А тут я с 60млн записей....

 

[Фанат]

какая связь между количеством запросов и количеством записей?

 

[Necromant]

А тут я с 60млн записей....

Граммотно ключи создай

 

[SelenIT]

все равно данные будут заполняться (и наверное читаться) все 400 чисел сразу.

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

MySQL позволяет вставлять сотни записей одним инсертом