Дилемма - "боевой" и "пользовательский" контент одного типа, как лучше хранить ?

t3[0one]

Новичок
Дилемма.
Реализую сущность - блюдо. У блюда есть привязки к другим блюдам.
Эти блюда заполняет специалист(администратор) , этот контент юзают пользователи.
У пользователей есть возможность создавать свои блюда и привязывать их как к своим блюдам , так и к блюдам специалиста. Собственно у меня дилемма - где хранить блюда ? В общей таблице или их отделить друг от друга - "боевой" контент от "пользовательского" с одним типом?
Разделение влечет за собой усложнение, общая таблица влечет за собой раздувание и захламлением таблицы с "боевым" контентом

Боевых записей - 2500-3000
Пользовательских записей - 1000000
Mysql. таблица имеет ~ 20 полей
Должен быть поиск по названию, как своих (пользовательских) записей, так и по записям специалиста
 
Последнее редактирование:
Серьёзно на этот вопрос ответить нельзя. Неясно что за блюда, принципиально ли они отличаются, какое у них взаимодействие с остальной частью приложения, неясен объём данных. Если возникает такой вопрос, то скорее всего тебе нужна одна таблица.
 
Серьёзно на этот вопрос ответить нельзя. Неясно что за блюда, принципиально ли они отличаются, какое у них взаимодействие с остальной частью приложения, неясен объём данных. Если возникает такой вопрос, то скорее всего тебе нужна одна таблица.
Про объемы уточняю, поспешил с вопросом , сори
принципиально ничем не отличаются, они одного типа

Уточнил,
Боевых записей - 2500-3000
Пользовательских записей - 1000000
Mysql. таблица имеет ~ 20 полей
 
Последнее редактирование:
Для современного железа таблица в пару миллионов записей - это совершенно обыденная вещь. Если у тебя нет fullscan-запросов, беспокоиться не о чем. А если есть, то в них и проблема.
 
Если же все же захочется отделить - всегда можно сделать партиционирование этой таблицы по флагу "системный/пользовательский". В современном mysql оно вполне себе нормально работает.
 
@fixxxer, ты чо, какое нафиг партицирование? нормализовать структуру, написать запросы, замерять что тормозит, выставить индексы, только после этого думать о чем-либо еще.
В этой задаче может быть только одна проблема - контексный поиск внутри строковых полей. Надо сразу озвучить - есть такая задача, или нет. Если есть - изучать полнотекстовые индексы.
 
@grigori, это само собой, это и имелось ввиду в первом комменте.

А партиционирование по флагу - тут это такой способ сделать аналог materialized views для "горячих" записей (которые не пользовательские). Не факт, что понадобится, конечно.
 
@fixxxer, ты чо, какое нафиг партицирование? нормализовать структуру, написать запросы, замерять что тормозит, выставить индексы, только после этого думать о чем-либо еще.
В этой задаче может быть только одна проблема - контексный поиск внутри строковых полей. Надо сразу озвучить - есть такая задача, или нет. Если есть - изучать полнотекстовые индексы.
Поиск по названию будет, то есть по 1 полю . Результат поиска в принципе можно отделить друг от друга
 
Боевых записей - 2500-3000
Это вообще можно в файле держать как кеш. Ну, т.е. хранить в БД, но при любом изменении можно целиком обновлять файл.

У меня ещё есть профессиональное заболевание, связанное с изучением предметных областей, а что это за блюда, что значит «боевые»? Что конкретно делают пользователи с ними? Готовите печенье с марихуаной по рецептам пользователей?
 
что значит «боевые»?
имею ввиду данные которые заполняет администратор и которыми пользуются все пользователи.
а что это за блюда
Блюда , сущности, автомобили - не важно )
Что конкретно делают пользователи с ними?
они копируют к себе данные и их могут модифицировать
Готовите печенье с марихуаной по рецептам пользователей?
типа того
 
Сверху