Сущности в БД

@rekooci · Регистрация: 10.08.2013

Студворк — интернет-сервис помощи студентам

Помогите определиться с сущностями для базы. Задача хранить рецепты и статьи. у рецептов те же поля, что и у статей плюс еще несколько других. У статей и рецептов свои категории. Вопрос. Статьи лучше хранить в одной базу с рецептами или разнести по разным?

@sKotenok · 14.09.2013, 03:10

rekooci, мало входных данных..
Если "рецепт" - это частный случай статьи с уточняющими параметрами - почему бы и нет..
Т.е. есть статьи - рецепты, есть статьи - новости, есть ещё какие-то; общие поля можно хранить в одной таблице, дополнительные в какой нибудь:
article_custom_fields(
article_id int -- FK
field_name varchar
field_value varchar
)

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

@rekooci · 14.09.2013, 09:44 **[ТС]**

спасибо. основное наполнение - рецепты. различие между статьями где-то 10 полей. я сначала сделал в разных таблицах, потому что так удобней делать выборку для отображения рецептов. но меня дублирование таблиц немного смущает - Рецепты, Категории для рецептов, Комментарии для рецептов и все то же самое для статей. Может стоит объединить разные категории и комментарии, добавив булево поле "тип". Посоветуйте как лучше, а то опыт работы небольшой.

@sKotenok · 14.09.2013, 11:53

rekooci, Тут тоже нет однозначного ответа.
Лично я бы не обьединял, наоборот предельно предельно разнёс их для уменьшения связности. Это позволит работать с рецептами и остальными статьями, как с независимыми сущностями (и в теории - разделить ответственность между разными людьми, если таковые имеются).
"Статьи" - слишком обобщённый термин, можно действительно разделить их по категориям (+1 таблица категорий), и, если это доп. плюшка, валить всё в кучу. Когда дорастёт до полноценного "большого" наполнения - подумать, есть ли смысл ещё что-то выделять (к примеру - статьи "обо всём" а ля ЖЖ стали частым явлением, а с какими-нибудь "новостями тайской кухни с рецептами" особо не попёрло, но доп. полей под них больше выделено).

С другой стороны, если "статья" рассматривается как частный случай рецепта и своих доп. полей не имеет, выделять отдельно - смысла нет. Это актуально при поиске, например. Хотя внедрение выделенного поискового движка вроде sphinx сильно уменьшит эту проблему (поиск по куче разных таблиц), но оно не каждому сайту нужно.

Новые блоги и статьи Все статьи Все блоги /
Символьное дифференцирование igorrr37 13.02.2026 / * Логарифм записывается как: (x-2)log(x^2+2) - означает логарифм (x^2+2) по основанию (x-2). Унарный минус обозначается как ! */ #include <iostream> #include <stack> #include <cctype>. . .	Камера Toupcam IUA500KMA Eddy_Em 12.02.2026 Т. к. у всяких "хикроботов" слишком уж мелкий пиксель, для подсмотра в ESPriF они вообще плохо годятся: уже 14 величину можно рассмотреть еле-еле лишь на экспозициях под 3 секунды (а то и больше),. . .	И ясному Солнцу zbw 12.02.2026 И ясному Солнцу, и светлой Луне. В мире покоя нет и люди не могут жить в тишине. А жить им немного лет.	«Знание-Сила» zbw 12.02.2026 «Знание-Сила» «Время-Деньги» «Деньги -Пуля»
SDL3 для Web (WebAssembly): Подключение Box2D v3, физика и отрисовка коллайдеров 8Observer8 12.02.2026 Содержание блога Box2D - это библиотека для 2D физики для анимаций и игр. С её помощью можно определять были ли коллизии между конкретными объектами и вызывать обработчики событий столкновения. . . .	SDL3 для Web (WebAssembly): Загрузка PNG с прозрачным фоном с помощью SDL_LoadPNG (без SDL3_image) 8Observer8 11.02.2026 Содержание блога Библиотека SDL3 содержит встроенные инструменты для базовой работы с изображениями - без использования библиотеки SDL3_image. Пошагово создадим проект для загрузки изображения. . .	SDL3 для Web (WebAssembly): Загрузка PNG с прозрачным фоном с помощью SDL3_image 8Observer8 10.02.2026 Содержание блога Библиотека SDL3_image содержит инструменты для расширенной работы с изображениями. Пошагово создадим проект для загрузки изображения формата PNG с альфа-каналом (с прозрачным. . .	Установка Qt-версии Lazarus IDE в Debian Trixie Xfce volvo 10.02.2026 В общем, достали меня глюки IDE Лазаруса, собранной с использованием набора виджетов Gtk2 (конкретно: если набирать текст в редакторе и вызвать подсказку через Ctrl+Space, то после закрытия окошка. . .

@rekooci 0 / 0 / 0 Регистрация: 10.08.2013 Сообщений: 23

	Сущности в БД 13.09.2013, 17:56. Показов 2589. Ответов 3 Метки нет (Все метки) Помогите определиться с сущностями для базы. Задача хранить рецепты и статьи. у рецептов те же поля, что и у статей плюс еще несколько других. У статей и рецептов свои категории. Вопрос. Статьи лучше хранить в одной базу с рецептами или разнести по разным? 0

@sKotenok 363 / 334 / 38 Регистрация: 29.03.2011 Сообщений: 838
	14.09.2013, 03:10
	rekooci, мало входных данных.. Если "рецепт" - это частный случай статьи с уточняющими параметрами - почему бы и нет.. Т.е. есть статьи - рецепты, есть статьи - новости, есть ещё какие-то; общие поля можно хранить в одной таблице, дополнительные в какой нибудь: article_custom_fields( article_id int -- FK field_name varchar field_value varchar ) Если сайт кулинарный и основное наполнение - рецепты, а остальные статьи - так, побаловаться, я бы вынес рецепты отдельно - будет удобнее с ними работать. 1

@rekooci 0 / 0 / 0 Регистрация: 10.08.2013 Сообщений: 23
	14.09.2013, 09:44 [ТС]
	спасибо. основное наполнение - рецепты. различие между статьями где-то 10 полей. я сначала сделал в разных таблицах, потому что так удобней делать выборку для отображения рецептов. но меня дублирование таблиц немного смущает - Рецепты, Категории для рецептов, Комментарии для рецептов и все то же самое для статей. Может стоит объединить разные категории и комментарии, добавив булево поле "тип". Посоветуйте как лучше, а то опыт работы небольшой. 0

@sKotenok 363 / 334 / 38 Регистрация: 29.03.2011 Сообщений: 838
	14.09.2013, 11:53
	rekooci, Тут тоже нет однозначного ответа. Лично я бы не обьединял, наоборот предельно предельно разнёс их для уменьшения связности. Это позволит работать с рецептами и остальными статьями, как с независимыми сущностями (и в теории - разделить ответственность между разными людьми, если таковые имеются). "Статьи" - слишком обобщённый термин, можно действительно разделить их по категориям (+1 таблица категорий), и, если это доп. плюшка, валить всё в кучу. Когда дорастёт до полноценного "большого" наполнения - подумать, есть ли смысл ещё что-то выделять (к примеру - статьи "обо всём" а ля ЖЖ стали частым явлением, а с какими-нибудь "новостями тайской кухни с рецептами" особо не попёрло, но доп. полей под них больше выделено). С другой стороны, если "статья" рассматривается как частный случай рецепта и своих доп. полей не имеет, выделять отдельно - смысла нет. Это актуально при поиске, например. Хотя внедрение выделенного поискового движка вроде sphinx сильно уменьшит эту проблему (поиск по куче разных таблиц), но оно не каждому сайту нужно. 0