Доброго времени суток, уважаемые.
Планирую структура сайта. У нашей фирмы есть филиалы. Каждый филиал имеет свою базу товаров и не должен иметь доступ к базе другого филиала. Реализовать структуру MySQL базы решил так:
Каждому филиалу создать свою базу, а потом объединять данные из всех баз во ВЬЮШКУ (в единую таблицу).
Как технически реализовать данный механизм (хостинг на своем сервере)?
1. Написать свое приложение на C++, которое каждые 5-10 сек, обновляла ВЬЮШКУ.
2. Использовать тригеры (после обновления таблицы любого из филиалов обновлять ВЬЮШКУ)
3. Ваше мнение?

Не будет ли сильно нагрузки при такой структуре, учитывая что ВЬЮШКА будет иметь внушительный размер после объединения товаров. Будут ли подвисания учитывая что структура таблицы ISAM и соответственно при обновлении данных происходит блокировка всей таблицы?

Есть ли преимущества в организации структуры сайта вида http://site[dot]ru/gorod1/prod.php против http://site.ru/prod.php?city=gorod1? Для чего делают структуру сайтов вида (http://site[dot]ru/gorod1/ http://site[dot]ru/gorod2/ http://site.ru/gorod3/) ?
Всем огромное спасибо!
С уважением и наилучшими пожеланиями lamer.

Делают потому что им не жалко использовать дисковое пространство.. А на первый вопрос нет ответа.. так как http://site[dot]ru/gorod1/prod.php это путь на скрипт, а http://site[dot]ru/prod.php?city=gorod1 это использование GET функций которые можно настроить под вывод из базы

Почитайте про ВЬЮ, если у Вас действительно много товаров, лучше использовать ИнноДБ myISAM может быть критично.
Я бы использовал одну БД. Если филиалов очень много разбейте их таблицы, а так индекс по филиалу и все нормально.
Почитайте теорию. На счет нагрузки, сделайте БД, заполните товарами и погоняйте ее.

А при чём тут дисковое пространство? Обычный ЧПУ.

Считается, что адреса http://site[dot]ru/gorod1/ приятнее пользователю, нагляднее поисковой машине и прочее.


Всегда лучше использовать InnoDB, как единственный из поддерживаемых и одновременно работающий типов транзакционных хранилищ.


Описания так же не пересекаются? Вообще, между ними много общего?
Может будет удобнее не мучать таблицы, а раскидать 1 филиал = 1 БД.

а что значит обновлять вьюшку

если имеется ввиду view (представление) то его невозможно и бессмысленно
просто изза отсутсвия предмета обновления


если все филиалы на одном сервере там и база должна быть одна - тут и думать нечего - синхронизация нескольких БД - страшный сон любого админа

таблица филиалов - остальное в привязке к ней по ключу


то что вы называете структурой сайта - просто настроенные удобм образом URL

В битриксе это обычные папки.

приятней пользоваться с помощью переключателей типа switch они и удобы и ссылки не длиные.. Например site.ru/?do=город1.. LIME разве ссылка вида site.ru/
gorod1/ это не обращение к папке gorod1 которая валяется в корне сайта?
(Добавление)
да и свичи при неверной ссылке не долго думают

во первых че вы к LIME прикопались он не при делах ))
во вторых намякиваю : ЧПУ и mod_rewrite
(Добавление)
свичам ссылки фиолетово они по IP работают

ну у меня так настроен nginx.. И если нет такой строчики в свиче значит моментально вылетает 404.. А ну да лайм сорри почему то пока писал ваш ник всплыл.. Мелкий вопрос переодресовываю к вам

Это может быть всё, что угодно. Зависит только от настройки веб-сервера.


Ну, кроме L3 свичей, свичи и об IP понятий не имеют. Работают по MACам.
Здесь, впрочем, речь о синтаксической конструкции switch. Адресную структуру на сетевых свичах делать - уникальной изощрённости разум!


Битрикс это вообще отдельная история

Вот и я о том же:
1БД=Один филиал, пусть там творят что хотят со своими правами, а потом уже собирать все данные в одну общую базу, поэтому то и возник вопрос технической реализации.

Хотя как быть если есть общие "системные" таблицы, например методы оплаты, кладр, способы доставки т.п. получается что в их базы тянуть ссылки на "системные" таблицы из общей базы? Анализируя это понимаю что возможно тогда лучше каждому филиалу дать таблицу (создать ЮЗЕРА с доступом только на эту таблицу), связать все таблицы филиалов с "системными" таблицами, а потом выбирать данные из этих таблиц в одну общую, или так не стоит делать?
(Добавление)

Да вы правы, VIEW динамисческая таблица, я имел ввиду некую общую таблицу куда будет по таймеру сливаться таблицы товаров всех филиалов.
А как в случае 1БД=1Филиал использовать VIEW насколько это рационально?

http://www[dot]deepserver[dot]ru/sharedimages/bitrix[dot]jpg

view - это просто sql запрос
он только упрощает написание других запросов

еще раз
храните все в одной базе - не ищите проблем с синхронизацией или репликацией

хотите разделить права - это можно сделать на уровне базы или на уровне логики сайта

тем более что остальным базам действительно могут понадобится данные с общей - какие нибудь справочники или классификаторы

впрочем если базы на одном сервере БД крутятся то обращатся к таблицам другой БД не проблемма, просто по мере изменения количества филиалов придется корректировать код либо извращатся и динамически запросы собирать в UNION

Как тогда выводит товары всех филиалов (то есть без дифференциации по филиалам), предварительно сливать все в общую таблицу, или в одном запросе все выбирать?

Одна таблица на всех. Выборка по id филиала, чо тут не понятного?