Консультация по структуре базы

Статус
Закрыто для дальнейших ответов.

mrlasking

$_GET['rich'] or die('trying');
Регистрация
22.05.2012
Сообщения
323
Вечер добрый, товарищи!) Вот понадобилась помощь и мне, в виде толковой консультации, очень на вас надеюсь.

Предыстория: Есть проект, посвященный туризму, который делался 2 года назад. Теперь встала задача его реанимировать и привести в божеский вид. Посмотрев на базу я уперся рогом в стенку и, к сожалению, не могу придумать альтернативы. С чем и прошу помощи.

Самые главные требования, которые нужно сохранить, но перепроектировать:
1. В системе есть разные, динамические (и это важно!), виды объектов. (Например: объекты питания, объекты проживания, посещения и проч.)
2. Характеристики этих объектов.
3. Собственно объекты.

А теперь, краткий экскурс в хаос ;) Как же это все реализовано:
(Выкладываю скринами, дабы сэкономить время вам и мне, кто сможет помочь - итак поймут, а кто не разберет - вряд ли поможет)
1. Таблица с типами объектов: obj.jpg. Колонка options_array хранит строку с айдишниками характеристик, соответствующих данному типу.
2. Таблица, описывающая характеристики: options.jpg
3. Таблица объектов: objects.jpg (достаточно маленькая и скромненькая в силу вынесения подавляющего большинства параметров в таблицу со значениями характеристик (№4) )
4. Таблица со значениями характеристик, для конкретного объекта: text_options.jpg. Вот эта таблица меня и смущает. Логика ее такова, что поля в которых object_id = 0, служат для генерации формы под данную характеристику (пример: form1.ipg). А поля с заполненными object_id, хранят значения для конкретных объектов.

Вот собственно после внесения нашим менеждером всего-то 350 объектов, размер таблицы text_options превысил 7500 строк и сомнения плотно засели у меня в мозгу.

Для ясности - я не прошу что-то реализовать за меня и т.д., все что нужно - я напишу сам ;) Я прошу помочь со структурой базы, ибо ожидаются несколько десятков тысяч объектов и такая структура как есть сейчас меня крайне стремает.

Так что, буду крайне благодарен за конструктивные идеи! Заранее спасибо. :ph34r:
 

Вложения

lekzd

parse error: parse error, unexpected T_STRING...
Регистрация
17.02.2011
Сообщения
1 125
десятков тысяч объектов
text_options можно уменьшить в N раз путем расширения таблицы полями для разных языков (при добавлении языка просто добавлять столбец)
обычно я называю поля так:
value_ru, value_en, value_ua - соответственно в SQLзапросе их следует брать как "value_".$lng_code." as value".
Остальные линковки в этой таблице я бы, оставил, может попробовал бы производительность с индексами и без.
 

mrlasking

$_GET['rich'] or die('trying');
Регистрация
22.05.2012
Сообщения
323
[member=lekzd], спасибо, идею понял. Но есть вопрос: используя эту идею, мы уменьшим таблицу в N раз, где N - кол-во языков активных. Но мы не избавимся того момента, что, при 90 характеристиках, создание каждого объекта будет влечь за собой создание 90 строк. Уже лучше, конечно, на данный момент, оно влечет создание, условно, 90*N строк.

Собственно вопрос - может имеет смысл в корне перепроектировать логику хранения информации об объекте? Или мне не париться по этому поводу, и это нормальная практика?
 

lekzd

parse error: parse error, unexpected T_STRING...
Регистрация
17.02.2011
Сообщения
1 125
это нормальная практика, не думаю, что стоит экономить на записи в таблицу, легче кешировать результаты чтения, ибо чтение происходит намного чаще
 
Статус
Закрыто для дальнейших ответов.
Верх Низ