lamer6666, из вашего описания проекта следует, что он немного выше по размеру и требованиям к исполнителям, чем средний уровень программистов на этом форуме, какие советы вы хотите услышать?
1. InnoDB или ISAM (Склоняюсь в пользу InnoDB)?
2. Какие проблемы могут возникнуть при использовании распределенной структуры (каждому филиалу выдать свою базу данных, или свою таблицу товаров с последующим объединением таблиц товаров в одну общую таблицу)?
3. Выше указанную общую таблицу создавать как виртуальную, или как обычную таблицу? Если как виртуальную, то это на мой взгляд создаст нагрузку на MySQL сервер, так как она будет формироваться каждый раз при запросе на web сервер со стороны посетителя. Или может создать обычную таблицу, которую обновлять тригерами после изменения данных в исходных (разделенных) таблицах?
lamer6666, если будет веб интерфейс накой делать прямые обращения к базе??
пусть все обращение десктопов будет через API сайта
тем самым кажды будет иметь только те права которые ему будут выделены
ну а заснифить если и получится только пароли доступа к интерфейсу
Понимаю вас, уважаемый DlTA. Данный вариант весьма проблематичен в реализации совместо с 1С, работа напрямую с MySQL сервером более быстрее и надежнее, к томуже механизм работы с MySQL базой из 1С уже готов и работает как часы.
Это вы такой умный траф снифать..
А бухгалтерша от слова "файервол" описаеца... Ламер
Ну не спорю уважаемый DeepVarvar, но все же, не в обиду будет сказано, я сторонник того 7 раз отмерить, 1 раз дать доступ. К тому же Бог его знает кто там будет работать, лишние возможные проблемы хочу учесть на стадии проектирования.
Поэтому всеже хотелось бы рассмотреть вариант разделенных таблиц. Каким лучшим образом из объединять? Метод предложенный LIME (Ха-ха выделить и скопировать?) уже учел .
lamer6666 ну вот вы сейчас пишете пост
он сохраняется в базе
попробуйте перехватить обращение к базе )))
При WEB интерфейсе это проблематично, а вот при использовании внешнего клиента это легко.
Например есть база 1С, Филиал№1 оотправлет из 1С список новых товаров в mySQL базу. Включай ПАРСЕР и смотри что программа отправляет.... вот о чем идет речь! Про WEB морду, спора нет, все идеально!
Что бы клиент подсоединился к MySQL БД, он обязан иметь ИМЯ ЮЗЕРА и ПАРОЛЬ от MySQL.
Даже если я разработаю некий сторонний механизм авторизации, где логин и пароль явно не имеют ничего общего с ЛОГИНОМ И ПАРОЛЕМ от MySQL базы данных, то при отправке данных (ЭКСПОРТ/ИМПОРТ) из приложения для добавления данных в БД, приложение обязано будет создать КОННЕКТ к базе данных используя параметры: (USER, PASSWORD, IP, DATABASE NAME) и по любому эти параметры даже скрытые от реального пользователя будут переданы и могут быть с легкостью перехвачены. Я сам так делал не раз.
Ограничение пользователя на сервере лучший вариант изоляции.
Неужели могут быть сложности в том что бы из таблиц:
Table1 (id,prodname,price)
Table2 (id,prodname,price)
Table3 (id,prodname,price)
.....
TableN (id,prodname,price)
в конечном итоге собрать одну таблицу: Table (id,idTableM,prodname,price) которую и выводит на сайт?
А когда посетитель выберет тот или иной товар из Table (id,idTableM,prodname,price), работать уже с конкретной таблицей TableN (id,prodname,price)?
помешает то что пользователи не будут знать пароли и тд
их будет знать приложение которое будет оперировать только с записями в которых прописан id его филиала
1. Пользователь запускает приложение, которое знает пароль и имя пользователя
2. Запускает HttpAnalyzerStdV6
3. Отправляет данные на MySQL сервер.
4. В HttpAnalyzerStdV6 ищет оправленные данные, в частности Логин и Пароль.
поэтому простите, но не вариант вшивать в СОФТ логин и пароль.
Лучше ограничить доступ на стороне сервера, поэтому то и отстаивают в обсуждении свою структуру.
Каждый филиал должен иметь изолированный доступ к своим товарам от других филиалов! Например в перспективе, нужно будет разработать приложение для автозагрузки товаров в каталог каждого из филиалов (например из 1С или др приложения). Таким образом, имея IP, USERNAME, PASSWORD программа автоматом подключается к хосту и сливает туда товары. Ничего не мешает пользователям имея ИМЯ ПОЛЬЗОВАТЕЛЯ и ПАРОЛЬ воспользоваться любым приложением, законектится к базе и делать с ОБЩЕЙ ТАБЛИЦЕЙ ТОВАРОВ все что угодно!
А если ЮЗЕРу прописанны права только на таблицу его филиала, и запрещен доступ к таблицам других филиалов, то вопрос разграничения доступа хоть как то, но решен.
Одна таблица на всех. Выборка по id филиала, чо тут не понятного?
Одна таблица на всех не катит. Права будет сложно раздать. Поэтому думал так:
1. База общая
2. Системные таблицы общие
3. У каждого филиала своя таблица товаров
4. У каждого филиала свое имя пользователя (чтение,запись своей таблицы товаров и чтение системных таблиц. Доступа к таблице чужого филиала нет). Таки образом стоит вопрос соединения таблиц товаров.
храните все в одной базе - не ищите проблем с синхронизацией или репликацией
Как тогда выводит товары всех филиалов (то есть без дифференциации по филиалам), предварительно сливать все в общую таблицу, или в одном запросе все выбирать?
Описания так же не пересекаются? Вообще, между ними много общего?
Может будет удобнее не мучать таблицы, а раскидать 1 филиал = 1 БД.
Вот и я о том же:
1БД=Один филиал, пусть там творят что хотят со своими правами, а потом уже собирать все данные в одну общую базу, поэтому то и возник вопрос технической реализации.
Хотя как быть если есть общие "системные" таблицы, например методы оплаты, кладр, способы доставки т.п. получается что в их базы тянуть ссылки на "системные" таблицы из общей базы? Анализируя это понимаю что возможно тогда лучше каждому филиалу дать таблицу (создать ЮЗЕРА с доступом только на эту таблицу), связать все таблицы филиалов с "системными" таблицами, а потом выбирать данные из этих таблиц в одну общую, или так не стоит делать? (Добавление)
caballero пишет:
если имеется ввиду view (представление) то его невозможно и бессмысленно
просто изза отсутсвия предмета обновления
Да вы правы, VIEW динамисческая таблица, я имел ввиду некую общую таблицу куда будет по таймеру сливаться таблицы товаров всех филиалов.
А как в случае 1БД=1Филиал использовать VIEW насколько это рационально?
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 39
К тому же Бог его знает кто там будет работать, лишние возможные проблемы хочу учесть на стадии проектирования.
