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 строк и сомнения плотно засели у меня в мозгу.
Для ясности - я не прошу что-то реализовать за меня и т.д., все что нужно - я напишу сам Я прошу помочь со структурой базы, ибо ожидаются несколько десятков тысяч объектов и такая структура как есть сейчас меня крайне стремает.
Так что, буду крайне благодарен за конструктивные идеи! Заранее спасибо. h34r:
Предыстория: Есть проект, посвященный туризму, который делался 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 строк и сомнения плотно засели у меня в мозгу.
Для ясности - я не прошу что-то реализовать за меня и т.д., все что нужно - я напишу сам Я прошу помочь со структурой базы, ибо ожидаются несколько десятков тысяч объектов и такая структура как есть сейчас меня крайне стремает.
Так что, буду крайне благодарен за конструктивные идеи! Заранее спасибо. h34r:
Вложения
-
41,5 КБ Просмотры: 37
-
83,3 КБ Просмотры: 37
-
91,4 КБ Просмотры: 38
-
32,7 КБ Просмотры: 36
-
141,4 КБ Просмотры: 37