Форум MySQL

Интересно было бы узнать, при создании сайта на типовых CMS программист имеет возможность задать тип и размерность поля в базе данных? Или, как правило, это ему недоступно, и система берет всё по максимуму на все случаи жизни?

конечно, ведь у него есть доступ к базе. вот только тип менять надо осторожно - varchar на text заменить можно (если не влезает текст, например), а вот int na varchar - вряд ли, ошибки могут возникнуть.

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

А не практикуется ли такой прием: все цифровые данные храним в int, а при их использовании средствами РНР или JavaScript переводим их в нужный вид?

тогда уж decimal (в int можно потерять дроби)...
а как вы тексты собираетесь в int хранить?

А в чем смысл замены ...

>А не практикуется ли такой прием: все цифровые данные храним в int, а при их использовании
>средствами РНР или JavaScript переводим их в нужный вид?
Хм... в int не очень много хранится, т.е. придется сильно данные разбивать, потом опять собирать, или вместо int имеется в виду text, varchar?

Текста практически нет - почти что одни числа, а вцелом записей прогнозируется под миллион, и в каждой записи по 20 столбцов. От дробей, в данном случае, можно освободиться, если писать в тысячных долях в одном столбце, в десятитысячных долях в другом столбце, и т.п.

Будет ли выигрыш в быстродействии, если организовать базу таким образом?

Быстродействие можно определить ..составив список всех запросов и на каждый смотреть EXPLAIN чтобы выяснить какие ставить индексы

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

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

PS Вообще CMS - она, как правило, объектно-ориентированная или предметно-ориентированная и очень часто попытка создания универсального решения выливается в конфликт с реляционно-декларативной природой СУБД. Простыми словами - прекрасный код CMS работает на хреновой базе данных, которая еле ворочается, так как её денормализовали по самые уши ради универсальной CMS (или хуже того, натолкали в неё XML или сериализованных объектов). Эта проблема не только PHP или Web, в свое время программирование пошло двумя путями: императивный (Fortran, С), который развился в объектно-ориентированный (C++, Java, PHP) и символьный (LISP), который развился в декларативный подход (Регулярные выражения, SQL). Они конфликтуют своей глубинной философией - одни описывают решения, другие - путь, поэтому совмещать их довольно сложно и сложно везде, во всех областях. Всегда приходится искать компромис, так как императивщиков подавляющее большинство, очень часто компромис не в пользу базы данных.