Что лучше несколько таблиц с несколькими колонками или одна таблица и много колонок

[bgraf]

Здравствуйте!

Подскажите, решаю такую проблему.

Сайт на php база данных mysql.

Есть данные организаций, название, телефон и все в таком духе примерно 14 колонок, есть еще вид деятельности, но их, видов, может быть более 20-ти, а еще есть 10 картинок их работ но тут есть колонка маленькая картинка, большая картинка и еще описание.

В общей сложности получится +/- 60 колонок.

Скажите как вы думаете лучше сделать одну такую таблицу или разделить на три, 1-я это данные фирмы, 2-я вид деятельности, 3-я картинки и связать их?

Как вы думаете что быстрее делать выборку из одной таблицы или связав из трех?

Спасибо за помощь!

Edited April 25, 2012 by bgraf

[rus]

не понятно написано, не хватает визуализационных данных в качестве представления.

выложи картинку, или html код того, что будет\должно быть на выходе.

[bgraf]

короче говоря есть 60 данных о компании.

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

[SelenIT]

Если кол-во видов деятельности фиксированное и каждая фирма может относиться к любому их числу (т.е. связь многие ко многим) — то конечно выносить их в отдельную таблицу и делать впридачу к ней таблицу связи вида "id фирмы — id вида деятельности". С правильными индексами будет не медленнее, чем одна монстроподобная таблица.

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

[bgraf]

Спасибо, все понял!

[s0rr0w]

Все зависит от того, как именно будет использоваться данные. Если не будет поиска по видам деятельности, то можно их записать в виде строки вида id,id,id...

При построении структуры СУБД можно идти по следующему пути: сначала все приводим к третьей форме нормализации, а потом ее денормализуем в другие структуры, которые помогут максимально быстро выводить контент.

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

[SelenIT]

Есть мнение, что прибегать к денормализации следует в самом крайнем случае, потому что сделать что-то типа materialized view для ускорения выборки из нормализованной базы (или еще как-нибудь закешировать результаты этой выборки) зачастую проще, чем спешно приделывать костыли к разросшейся денормализованной, если этот поиск по видам деятельности ВНЕЗАПНО всё-таки понадобится...

[s0rr0w]

Есть мнение, что прибегать к денормализации следует в самом крайнем случае, потому что сделать что-то типа materialized view для ускорения выборки из нормализованной базы (или еще как-нибудь закешировать результаты этой выборки) зачастую проще, чем спешно приделывать костыли к разросшейся денормализованной, если этот поиск по видам деятельности ВНЕЗАПНО всё-таки понадобится...

Materialized views является одним из способов денормализации.

[SelenIT]

Но на то он и view, что сами данные при этом хранятся в виде, удобном для поиска

[s0rr0w]

Но на то он и view, что сами данные при этом хранятся в виде, удобном для поиска

Не только