(PHP) Создание многосайтового магазина

twistfire
Дата: 03.08.2006 10:14:50
Сейчас проектаируется приложение - интернет-магазин.
Реализована простая структура рубрикатора, система заказаов - односложная система администрироваания.

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

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

Причем добавляют товары разные люди, - соответсвенно раздавать права (привилегии дял пользователей/администраторов) тоже как-то нужно.

Расскажите как такое можно оргнизовать в плане логики приложения?

База у всех магазинов общая.
AlexTheRaven
Дата: 03.08.2006 10:42:09
twistfire
Сейчас проектаируется приложение - интернет-магазин.
Реализована простая структура рубрикатора, система заказаов - односложная система администрироваания.

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

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

Причем добавляют товары разные люди, - соответсвенно раздавать права (привилегии дял пользователей/администраторов) тоже как-то нужно.

Расскажите как такое можно оргнизовать в плане логики приложения?

База у всех магазинов общая.


IMHO:
Собственно, общая БД с товарами и настройками. Все сайты - программно одинаковые, с механизмом централизованного обновления кода, но настройки для них разные.

Права можно раздавать на уровне БД и/или интерфейса.
twistfire
Дата: 03.08.2006 12:41:54
Как можно орагнизовать такую раздачу прав?
Чтобы на одноммагмзине показыались товары а на другом нет?

Я имею в виду оптимальный по затратам вариант (с Вашей точки зрения)
AlexTheRaven
Дата: 06.08.2006 00:41:18
twistfire
Как можно орагнизовать такую раздачу прав?
Чтобы на одноммагмзине показыались товары а на другом нет?

Я имею в виду оптимальный по затратам вариант (с Вашей точки зрения)


1) Если не предполагается впоследствии переходить с одной СУБД на другую - я бы сделал на уровне СУБД. Разные программы-магазины при отображении товаров работают с БД от имени разных пользователей. А уже для этих пользователей настраивается, информацию о каких товарах они могут считывать (и отображать). По-моему - это наименее затратный вариант. Но тогда надо изначально использовать заведомо достаточную, развитую и сложную СУБД.

2) Можно использовать view, но IMHO это "кривее" и будущие затраты могут быть больше.

3) Если вероятность перехода есть - то я бы сделал (и уже делал) на уровне web-сервера, а именно слоя абстракции от СУБД. Но это затратнее (1) и (2), и является изобретением велосипеда.
twistfire
Дата: 06.08.2006 11:09:02
а можно поподробнее о споспобе с БД.
На данный момент работает все на PostgreSQL

Я просто не программер в принципе, что-то понимаю, постараюсь понять.

То есть я завожу различных юзеров для бд, потом клиенты просто все одинаковые - с разными юзерами.

А как настроить базу так, чтобы она кому-то что-то отдававала а кому-то нет?
Что есть какие-то встроенные в БД примочки которые одним юзерам разрешают читать часть таблицы а другим нет?
Или организовать дополнительную таблицу юзеров которые... что?
AlexTheRaven
Дата: 07.08.2006 23:41:31
twistfire
а можно поподробнее о споспобе с БД.
На данный момент работает все на PostgreSQL

Я просто не программер в принципе, что-то понимаю, постараюсь понять.

То есть я завожу различных юзеров для бд, потом клиенты просто все одинаковые - с разными юзерами.

А как настроить базу так, чтобы она кому-то что-то отдававала а кому-то нет?
Что есть какие-то встроенные в БД примочки которые одним юзерам разрешают читать часть таблицы а другим нет?
Или организовать дополнительную таблицу юзеров которые... что?


Готовое решение, извиняйте, не дам. Не ахти какое изобретение, но некорректно это по отношению к моему предыдущему работодателю.

По поводу кривоватого и половинчатого пути реализации row-level security в PostgreSQL: тынц. См. GRANT полномочия на VIEW.

По поводу изобретения велосипеда с собственными предикатами безопасности - например, тынц.

А вот в Oracle и DB2 всё значительно прямее. Хотя стоит ли оно нескольких лет жизни, вложенных в изучение такой СУБД?
twistfire
Дата: 08.08.2006 12:09:39
спасибо.