Вопрос о хранении контента в базе данных

[CHEM_Eugene]

Вопрос о хранении контента в базе данных

Разрабатываю свой движок. Помогите определиться как оптимально хранить данные о контенте в базе данных (mysql).
Контент хочу подразделить на:
1. статический текстовый, редактируется при помощи WYSIWYG
2. прикрепляемые images
3. любой другой (текстовые файлы, pdf и т.д.).

Вопрос - хранить данные разных типов в одной таблице или разделить скажем на 3: content, images, attachements ?
Посмотрел реализацию в различных системах, честно говоря не очень впечатлило. Например, в wordpress - 1 таблица с 24 полями, из них только на 3 стоят индексы и 15 из 24 полей обычно (например для картинки) остаются пустыми. Скорость выборки из них просто отвратительная.

Расскажите, кто как реализовал при проектировании.

 

[jonjonson]

Сделай как проще и удобней.

 

[CHEM_Eugene]

Автор оригинала: jonjonson
Сделай как проще и удобней.

Да и так и так не сложно сделать. Т.е. я так понимаю ни у кого мнений по этому поводу больше нет?

 

[zerkms]

из них только на 3 стоят индексы

и что?
почитай про индексы.

15 из 24 полей обычно (например для картинки) остаются пустыми. Скорость выборки из них просто отвратительная.

из первой половины цитаты вторая совсем не следует

предложенный тобой вариант вполне удобен

 

[AmdY]

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

 

[CHEM_Eugene]

Автор оригинала: zerkms
из первой половины цитаты вторая совсем не следует

А тут никаких причинно-следственных связей нет. Это просто перечисление фактов - то, что замечено на практике.

А ещё хотелось бы услышать примерчик из своей (т.е. вашей) практики разработки. Вашу реализацию

-~{}~ 08.02.08 09:22:

Автор оригинала: AmdY
контент лучше и проще хранить в базе.
а вот картинки ты как вставляешь в WYSIWYG, неужели используешь файл менеджер который выбирает картинки и хранит их в базе?
в очень редниких случаях хранения хранине изображений в базе данных оправдоно.

Картинки естественно в базе не лежат. Сохраняется только ссылка на файл и устанавливается связь между файлом и материалом, к которому этот файл "прикреплен" или же файл может просто валяться в хранилище без связи с материалом, тогда он должен быть доступен через файл-менеджер.
Функцию загрузки картинок тоже думаю исключить из WYSIWYG, а написать свой загрузчик, который будет производить осмысленную загрузку, а не просто валить все в одну папку.

 

[jonjonson]

А ещё хотелось бы услышать примерчик из своей (т.е. вашей) практики разработки. Вашу реализацию

Зависит от конкретной ситуации. Круглого коня в вакууме на все случаи жизни не изобретал.

 

[octan]

Контент нужно хранить в базе данных, (иначе зачем вообще база данных если содержимое сайта будет храниться в текстовых файлах) а все остальные файлы ныжно хранить в определенных папках на серваке, и в базе хранить только имена фйлов и их тип. На пример изображение image.jpg можно хранить в папке images а в базу добавить только image.jpg и тип файла - image.

 

[CHEM_Eugene]

Автор оригинала: octan
Контент нужно хранить в базе данных, (иначе зачем вообще база данных если содержимое сайта будет храниться в текстовых файлах) а все остальные файлы ныжно хранить в определенных папках на серваке, и в базе хранить только имена фйлов и их тип. На пример изображение image.jpg можно хранить в папке images а в базу добавить только image.jpg и тип файла - image.

Гениально, как я сам не догадался !

-~{}~ 08.02.08 13:04:

Автор оригинала: jonjonson
Круглого коня в вакууме на все случаи жизни не изобретал.

Но так тянет изобрести, не правда ли?

 

[Духовность™]

ениально, как я сам не догадался !

что смешного?

 

[CHEM_Eugene]

Автор оригинала: triumvirat
что смешного?

А вам не кажется предложенное очевидным как 2*2 = 4 ?

Мне интересны способы организации таблиц в базе. Про это и спрашивал.

 

[Духовность™]

А вам не кажется предложенное очевидным как 2*2 = 4 ?

Каков вопрос, таков ответ. Вы спросили как лучше хранить - вам ответили.

Мне интересны способы организации таблиц в базе.

А чего сложного, я не пойму? Или что непонятного? Кажется очевидным, если хранить картинки, например к статье, для этого надо таблицу отношений иметь.

 

[octan]

Мне интересны способы организации таблиц в базе. Про это и спрашивал.

Во первых. Вы задали ваш вопрос не в тот топик, здесь обсуждаются "Вопросы по программированию на РНР" а для таких вопросов есть специальный топик - "PHP & Mysql" там и задавайте вопросы на тему работы с базами данных.

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

http://support.microsoft.com/kb/283878/ru

 

[Curly-fingers]

octan
Фу блин, нашли где читать

 

[octan]

Curly-fingers
Да эта ссылка скрее для того чтобы человек понимал о чем я говорю. Кстати, там этот вопрос описывается достаточно не плохо.

 

[dimagolov]

octan, прикол в том, что часто именно ради производительность нормализацией БД жертвуют. только это делают тогда, когда очень хорошо понимает что и зачем происходит на уровне реализации СУБД.

 

[Sluggard]

Картинки естественно в базе не лежат. Сохраняется только ссылка на файл

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

Гениально, как я сам не догадался

что смешного?

octan, triumvirat
Вам не кажется, что надо читать внимательнее топикстартера? В его первом посте вопрос звучит так:

Вопрос - хранить данные разных типов в одной таблице или разделить скажем на 3: content, images, attachements ?

CHEM_Eugene
из твоих постов не видно, по каким причинам ты должен использовать отдельные таблицы для images и attachements.

 

[CHEM_Eugene]

Автор оригинала: Sluggard
из твоих постов не видно, по каким причинам ты должен использовать отдельные таблицы для images и attachements.

А разве разумно при помещении в такую таблицу (24 поля) ссылки на картинку использовать только 4 поля, а именно:
1. id
2. parent_id (материал, к которому прикреплен)
3. собственно ссылка на файл
4. mime-type

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

 

[Sluggard]

где-то нужны 24 поля, где-то 150.

А разве разумно при помещении в такую таблицу (24 поля) ссылки на картинку использовать только 4 поля

Нет, не разумно. Если ты используешь только 4 поля, значит остальные 20 следует удалить.