que_bunt
Новичок
хочу написать движок для ускореной разработки "стандартных" сайтов, есть вопросы.
здраствуйте.
задача: написать движок, модификация которого при каждой новой разработке стандартного сайта (решения типа "расширеная визитка" - новости, статьи, каталог продукции, текстовые страницы) сводилась бы к минумуму.
а также устранить постоянную нужду лазить и изменять в класах функции добавления/удаления (Insert&Update) например позиций каталога при смене характеристки позиций. Тоесть например(упрощенно) для каждой позиции есть характеристики: высота и ширина, а в новом проекте добавился вес, соответственно надо идти добавить поле в структуру таблицы items, потом надо лезть в класс, менять у всех функциях все INSERT&UPDATE, добавить в формы поля для ввода этих даных, добавить в контроллер проверку на это поле, добавить это поле в шаблоне вывода, вот такую процедуру хотелось бы минимизировать.
интересует именно правильно ли я продумал структуру приложения и бд.
и выдержит ли такая структура нагрузку например 100 000 хитов в день при 50 000 позиций каталога в базе.
итак:
главная таблица
pages:
id
type - тип страницы (staticcontent, dir, catalog_root, catalog_branch, catalog_root_branch)
name - название страницы
nice_name - название для ЧПУ
parent_id - родитель
path - путь ЧПУ
title - тег title на странице
sort_order - позиция при выводе.
при заходе на страницу в front-end наши действия:
1) получаем информ. о странице по ее пути
2) в зависимости от типа страницы выдаем контент:
детальнее пункт 2:
2.1) если type=staticcontent, то просто берем контент из таблицы
staticcontent:
id
page_id
content (longtext)
2.2) если type=dir то выводим список подстраниц (шаблон вывода это уже мелочи)
2.3) если type=catalog_root, то выводим все категории каталога.
2.4) если type=catalog_branch, то выводим все позиции этой категории информацию (характеристики) для которых мы берем из таблиц:
items
id
item_class_id - тип позиции (если есть разные типы - фотоапараты и холодильники - хар-ки разные ведь)
cat_id - категория,=id с таблицы pages
name - название
nice_name - название для ЧПУ
path - путь для ЧПУ
user_id - ид юзера который добавил товар в базу
add_datetime - дата добавления
edit_datetime - дата последнего редактир.
sort_order - позиция в выводе.
и
itemdbelements
id
formelement_name - название характеристики
formelement_value - значение хар-ки
item_id - id позиции с табл. items
2.5) если type=catalog_branch и задана конкретная позиция - воводим информацию об этой позиции, беря информацию из тех же двух таблиц items и itemdbelements.
2.6) catalog_root_branch - тип страницы обьединивший catalog_root и catalog_branch, тоесть тот же каталог, только без подкатегорий, одноуровневый.
по сути получаеться что например те же простенькие новости (или статьи) это и есть в моей структуре catalog_root_branch, раздел с позициями с одной характеристикой (полем для заполнения при добавлении позиции) "текст".
фотогалерея с подразделами - получаеться catalog_root с позициями с характеристиками: подпись, большой рисунок, маленький рисунок.
теперь если к хар-кам позиции каталога (ширина и высота) добавить вес то уже не надо будет идти и менять структуру таблици.
теперь как создаеться форма добавления\редактирования:
есть таблицы
itemclasses - типы позиций
id
name - название типа (фотоапарат, холодильник)
sort_order
formelements - поля различных форм добавления\редактирования.
id
type - типа поля(text, textarea, select, price)
name - название
caption - подпись к полю при заполнении
default_value - значение по умолчанию
field_elements - возможные значении поля (например для select)
size - размер поля
maxlength - максимальная длина
require - обьязательность при заполнении
hint - подсказка при заполнении
searchable - будет ли производиться поиск по полю
search_type - тип поиска по полю (FullText, Like, == и тд.)
sort_order - позиция при выводе формы
class_formelement - какие поля в формах добавления\редактирования к каким типам позиций.
(многие ко многим: formelements<->itemclasses)
id
item_class_id - тип позиций
formelement_id - поле формы
Соответственно при добавлен.\редактиров. создаем форму так:
- выбираем тип добавляемой позиции.
- берем все поля форм из formelements для типа добавляемой позиции (item_class).
- рендерим форму
- если заполнена валидуем форму
- стандартные поля пишем в items
- дополнительные в itemdbelements.
вроде все не очень сложно.
видимые мной возможные проблемы:
1) есть запись позиции, есть стандартние поля:
например 3: категория, название, дата добавления
есть другорятные 7: краткое описание, полное описание, контактное лицо, телефон, e-mail, сайт, адрес.
есть ли большая разница?
1 таблица: 10 столбцов
или
2 таблицы: 3 столбца и 2 столбца по 7 записей?
по сути в два раза большый обьем бд получаеться =(
2) вытекает из первой проблемы:
выборку позиции надо делать:
что наверное будет медленней при больших нагрузках чем:
а если надо выбрать все позиции какой-то категории, то вообще получаем что количество запросов к бд возрастает по геометричной прогресси 1 запрос для выбора всех позиций категории из ITEMS_TABLE + для каждой позиции по запросу на выборку характеристик из ITEMDBELEMENTS_TABLE.
как вы думаете есть ли смысл в такой структуре построения движка? правильно ли я хоть какую-то часть спроектировал? или это все бред?
и реальны ли те проблемы которые я вижу?
возможно есть еще масса других проблем которые я из-за неопытности не вижу?
реальна ли для такой структуры нормальная нагрузка в тех же например 100 000 хитов (при количестве в 50 000 позиций в каталоге + по 50-15 характеристик для каждой позиции в таблице ITEMDBELEMENTS_TABLE в день (цыфри примерные, скорее максимально возможные для меня, но все же)?
если нет то сколько навскидку она вообще выдержит?
-~{}~ 19.12.06 19:23:
если я что-то не понятно обьясняю, скажите - обьясню детальнее, очень бы хотелось получить несколько вразумительних мнений.
здраствуйте.
задача: написать движок, модификация которого при каждой новой разработке стандартного сайта (решения типа "расширеная визитка" - новости, статьи, каталог продукции, текстовые страницы) сводилась бы к минумуму.
а также устранить постоянную нужду лазить и изменять в класах функции добавления/удаления (Insert&Update) например позиций каталога при смене характеристки позиций. Тоесть например(упрощенно) для каждой позиции есть характеристики: высота и ширина, а в новом проекте добавился вес, соответственно надо идти добавить поле в структуру таблицы items, потом надо лезть в класс, менять у всех функциях все INSERT&UPDATE, добавить в формы поля для ввода этих даных, добавить в контроллер проверку на это поле, добавить это поле в шаблоне вывода, вот такую процедуру хотелось бы минимизировать.
интересует именно правильно ли я продумал структуру приложения и бд.
и выдержит ли такая структура нагрузку например 100 000 хитов в день при 50 000 позиций каталога в базе.
итак:
главная таблица
pages:
id
type - тип страницы (staticcontent, dir, catalog_root, catalog_branch, catalog_root_branch)
name - название страницы
nice_name - название для ЧПУ
parent_id - родитель
path - путь ЧПУ
title - тег title на странице
sort_order - позиция при выводе.
при заходе на страницу в front-end наши действия:
1) получаем информ. о странице по ее пути
2) в зависимости от типа страницы выдаем контент:
детальнее пункт 2:
2.1) если type=staticcontent, то просто берем контент из таблицы
staticcontent:
id
page_id
content (longtext)
2.2) если type=dir то выводим список подстраниц (шаблон вывода это уже мелочи)
2.3) если type=catalog_root, то выводим все категории каталога.
2.4) если type=catalog_branch, то выводим все позиции этой категории информацию (характеристики) для которых мы берем из таблиц:
items
id
item_class_id - тип позиции (если есть разные типы - фотоапараты и холодильники - хар-ки разные ведь)
cat_id - категория,=id с таблицы pages
name - название
nice_name - название для ЧПУ
path - путь для ЧПУ
user_id - ид юзера который добавил товар в базу
add_datetime - дата добавления
edit_datetime - дата последнего редактир.
sort_order - позиция в выводе.
и
itemdbelements
id
formelement_name - название характеристики
formelement_value - значение хар-ки
item_id - id позиции с табл. items
2.5) если type=catalog_branch и задана конкретная позиция - воводим информацию об этой позиции, беря информацию из тех же двух таблиц items и itemdbelements.
2.6) catalog_root_branch - тип страницы обьединивший catalog_root и catalog_branch, тоесть тот же каталог, только без подкатегорий, одноуровневый.
по сути получаеться что например те же простенькие новости (или статьи) это и есть в моей структуре catalog_root_branch, раздел с позициями с одной характеристикой (полем для заполнения при добавлении позиции) "текст".
фотогалерея с подразделами - получаеться catalog_root с позициями с характеристиками: подпись, большой рисунок, маленький рисунок.
теперь если к хар-кам позиции каталога (ширина и высота) добавить вес то уже не надо будет идти и менять структуру таблици.
теперь как создаеться форма добавления\редактирования:
есть таблицы
itemclasses - типы позиций
id
name - название типа (фотоапарат, холодильник)
sort_order
formelements - поля различных форм добавления\редактирования.
id
type - типа поля(text, textarea, select, price)
name - название
caption - подпись к полю при заполнении
default_value - значение по умолчанию
field_elements - возможные значении поля (например для select)
size - размер поля
maxlength - максимальная длина
require - обьязательность при заполнении
hint - подсказка при заполнении
searchable - будет ли производиться поиск по полю
search_type - тип поиска по полю (FullText, Like, == и тд.)
sort_order - позиция при выводе формы
class_formelement - какие поля в формах добавления\редактирования к каким типам позиций.
(многие ко многим: formelements<->itemclasses)
id
item_class_id - тип позиций
formelement_id - поле формы
Соответственно при добавлен.\редактиров. создаем форму так:
- выбираем тип добавляемой позиции.
- берем все поля форм из formelements для типа добавляемой позиции (item_class).
- рендерим форму
- если заполнена валидуем форму
- стандартные поля пишем в items
- дополнительные в itemdbelements.
вроде все не очень сложно.
видимые мной возможные проблемы:
1) есть запись позиции, есть стандартние поля:
например 3: категория, название, дата добавления
есть другорятные 7: краткое описание, полное описание, контактное лицо, телефон, e-mail, сайт, адрес.
есть ли большая разница?
1 таблица: 10 столбцов
или
2 таблицы: 3 столбца и 2 столбца по 7 записей?
по сути в два раза большый обьем бд получаеться =(
2) вытекает из первой проблемы:
выборку позиции надо делать:
PHP:
$sql="SELECT * FROM ".ITEMS_TABLE." WHERE path='".$this->safe_data($path)."'";
$result=mysql_query($sql) or $this->error(mysql_error());
$item=mysql_fetch_assoc($result);
//для позиции выбираем dbelements
$sql="SELECT * FROM ".ITEMDBELEMENTS_TABLE." WHERE item_id='".$item['id']."'";
$result=mysql_query($sql) or $this->error(mysql_error());
while($row=mysql_fetch_assoc($result)) {
$item[$row['formelement_name']]=$row['formelement_value'];}
PHP:
$sql="SELECT * FROM ".ITEMS_TABLE." WHERE path='".$this->safe_data($path)."'";
$result=mysql_query($sql) or $this->error(mysql_error());
$item=mysql_fetch_assoc($result);как вы думаете есть ли смысл в такой структуре построения движка? правильно ли я хоть какую-то часть спроектировал? или это все бред?
и реальны ли те проблемы которые я вижу?
возможно есть еще масса других проблем которые я из-за неопытности не вижу?
реальна ли для такой структуры нормальная нагрузка в тех же например 100 000 хитов (при количестве в 50 000 позиций в каталоге + по 50-15 характеристик для каждой позиции в таблице ITEMDBELEMENTS_TABLE в день (цыфри примерные, скорее максимально возможные для меня, но все же)?
если нет то сколько навскидку она вообще выдержит?
-~{}~ 19.12.06 19:23:
если я что-то не понятно обьясняю, скажите - обьясню детальнее, очень бы хотелось получить несколько вразумительних мнений.
мне страшно представляю как неповезёт тем кто после нас заглянет. Да и опыт у меня =( я месяц назад о ООП только слышал первый раз
потому решил спросить на форуме, просто не могу понять почему? и как тогда организовывается такая универсальнсоть как я описал? (хоть на пальцах обьясните пожалуста).
