680 тысяч записей - нормально для MySql

IceNinja

Новичок
Делаю каталог на YII.
Предполагается несколько типов объектов, скажем, А, B и С, причём вот в такой родительской иерархии - A > B > C.
Объектов типа С предполагается около 15 тысяч в БД. А объектов А и B - существенно меньше, может, вместе наберётся ну две тысячи максимум..

Суть вот в чём. Где-то нужно хранить свойства этих объектов, причём есть два важных момента:
1) В принципе, наборы свойств для разных типов объектов различаются. Т.е. для А - это несколько свойств, около 5-10, для объектов типа В - ну тоже где-то столько же, а для С - около 15-20 свойств, может быть и больше, допустим, 20. Всего свойств, выходит, 20 + 10 + 10 = 40 где-то.
2) и при этом нужно иметь возможность добавлять ещё свойства, например, объекту типа А добавить несколько свойств, для него нехарактерных.

Короче, решил я это дело хранить так - объекты в одной таблице, свойства в другой, наборы свойств - в третьей, а саму связь свойств с объектами - в четвёртой. Примерно как-то так:

И вот эта четвёртая таблица вызывает у меня нервяк. Если там будет (15000 + 2000 )* 40 = 680000 записей. Не просяду ли я с таким объёмом? Объекты нужно будет фильтровать там, то, сё. Не слишком ли это большие размеры? Может, вместо Мускула использовать что-то ещё?
 

radioheaded

PHP нуб
Не просяду ли я с таким объёмом? Объекты нужно будет фильтровать там, то, сё. Не слишком ли это большие размеры? Может, вместо Мускула использовать что-то ещё?
Не просядите ли когда, при каких условиях? Не слишком ли большие для чего? Вы могли бы задать эти же вопросы, не описывая всей структуры, они при этом были бы настолько же информативны.
Могу ответить абстрактно в вакууме: на мускуле держат базы на порядки превосходящие вашу. Даже если вы опишете ваше железо, ваш трафик по часам, характер этого трафика, вашу архитектуру приложения и кеширование в нем, то все равно точно вам никто не сможет ответить на этот вопрос. Единственное, что можно точно сказать, то, что я уже написал выше.
 

IceNinja

Новичок
Согласен, информации дал мало. Вообще меня даже больше интересует другой вопрос - насколько правильно ли спроектирована БД с точки зрения оптимального быстродействия?
На сайте (фронтенд) предполагается поиск по фильтру определённый свойств, а в админке:
1) CRUD-интерфейс любого свойства
2) CRUD-интерфейс любого набора свойств
3) CRUD-интерфейс любого объекта c заданием значений конкретных свойств
Права и прочее будут реализованы потом, сейчас интересуют пока только вышеупомянутые вещи.

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


Кто-то мне рекомендовал выносить свойства для разных типов объектов в разные таблицы, типа:
Таблица с свойствами класа А (колонки - свойста, записи - объекты)
Таблица с свойствами класа B (колонки - свойста, записи - объекты)
Таблица с свойствами класа C (колонки - свойста, записи - объекты)
Соответсвенно в каждой таблице ключ - идентефикатор объекта. Соответсвенно объект класа С имеет записи со свойствами во всех трех таблицах, объект класа А только в первой.
Но что-то мне кажется, что это бредово, учитывая, что свойства нужно динамически добавлять и удалять.
 

assous

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

GoodLuck777

Новичок
680 000 записей фигня для базы данных, индексы правильные и все будет летать
 
Сверху