Доброго времени суток!
Есть вопрос относительно надёжности и быстродействия базы данных.
Вопрос скорее к оптимизаторам БД.
Цель разработка интернет каталога примерно на 10 - 15 тысяч записей.
Как будет лучше, использование одной таблицы в которой будет порядка 80 полей, треть из которых VARCHAR, а остальные DOUBLE и INTEREGER. В которой все поля ИНТ будут индексами, по которым будет идти поиск.
Или же лучше сделать примерно 7 - 8 таблиц в которых будет по 13 - 15 полей, где порядка 10 из них будет VARCHAR?

Какой из этих вариантов наиболее жизнеспособный?

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

Ещё интересен вопрос по поводу кеша. Как можно закешировать возвращённый результат, чтобы при повторном таком запросе, ДБ выдала результат на много быстрее. и держала в памяти этот ответ каких минут 30 если не было никаких изменений в данной таблице... 

Касательно последнего, возможно ли такое вообще?

Какие поля будут в таблице: (по бумажный вариант)

Имхо Вы не там видите минус, где он есть.
Сохранность и доступность данных не задача программиста, задача DBA./*конечно от программиста при том требуется соблюдение определенных правил, но тут, ИМХО вовсе не тот случай*/
А минус денормализации - существенное  усложнение процесса модификации данных и обеспечения  их согласованности.
Денормализация с целю оптимизации доступа по чтению - вполне себе общепринятая практика.



Это сообщение отредактировал(а) Zloxa - 11.10.2010, 17:12

Я согласен, что при внесении дополнений в структуру таблицы, я буду её нагружать ещё круче, учитывая что нововведение не нужно для всех видов товара а только для конкретной категории.
Ну а в целом, как я понимаю, мой вариант реализации каталога вполне имеет право на существование и очень даже нормальное?

Хочется ещё плюсов и минусов от специалистов. Критика допускается!

Ты не правильно понял озвученный мною минус.
Я говорил о модификации и согласованности данных, а не структуры. Ну да то ладно. Если ты не видишь в этом проблемы, может статься, ее и нет. О чем тогда говорить?

Еще в качестве проблемы можно придумать объем. Определенно сканирование таблицы с 1-2 тыщ записями будет производиться быстрее чем одной 13-15тыщ. Но об этом тоже сложно говорить, не понимая какого рода запросы будут превалировать.

Добавлено через 3 минуты и 49 секунд
В общем резюме. Делай. Такой подход, при таких исхдных - вполне жизнеспособен.
А там, как граблей в лоб получишь - обращайся, посочувствуем, на вавку подуем, расскажем как правильно надо было, с учетом внезапно всплывшего.

Ок! Будем пробовать и смотреть. А проблемы будем решать по мере поступления.

З.Ы. Что означает: согласованность данных? 

Это сообщение отредактировал(а) xoslv - 13.10.2010, 09:33

Под согласованностью я понимал консистентность, но это слово мне не нравится. В этой статье согласованность является одним из условий консистентности, а, скажем, в этой - синонимом.

Добавлено @ 10:05
На примере приведенной тобой структуры:
Допустим поле language, у тебя могут оказаться значения 'Русский' и 'Русcкий'(с одной латинской с), которые обозначают одно и то же, но суть разнятся. Это называется противоречивость данных - нарушение согласованности(консистентности).
В нормализованной структуре, обеспечить подобную непротиворечивость данных - несколько проще. 

Это сообщение отредактировал(а) Zloxa - 13.10.2010, 10:08

Здорово, спасибо! Полезные статейки!