Привет всем!
У меня возникла концептуальная проблема.
Помогите придумать наиболее грамотный механизм, плиз!!!

Дело вот в чем:
у меня есть база данных (сетевая).
Она огроменная и в ней много инфы, особенно той, которую НУ никак не желательно потерять.
Маленькую часть данных (очень маленькую) необходимо публиковать на сайте. С сайта авторизированные пользователи могут ее просматривать.
Так же на сайте возможно регистрация новых пользователей.
И ввод ими части данных. Эта часть потом должна попасть в сетевую базу.
НО! Сетевую базу к интернету я подключать не имею желания. На ней и так большая нагрузка.
И она тогда вообще загнется, а этого допустить нельзя.
Да и там много других причин. Но факт ее НЕ-подключения 100 %.
Поэтому я хочу периодически выкачивать запросик необходимые данные и помещать их в бд для сайта (mySQL).
Проблема заключается в авторизации пользователй.
дело в том, что информацию могут смотреть "заявители" из сетевой базы. на местах им выдают логин и пароль для входа на сайт. он будет хранится в базе и больше не для чего не используется там. Но вот только не знаю, как его хранить в базе my-sql?
ТОли в зашиврованном виде в таблице, толи периодически с каждым оьбновлением генерить к базе пользователей с паролями??

Но это еще пол-беды. Хуже всего , что "заявитель" изначально может появиться в интернете, т.е. у него не будет никакого логина и пароля. А мне надо ж его тоже авторизовать. Он там вводит заявку, и она письмом (не в базу!!!! т.к. прежед человек должне проверить, что это не спам и настоящая заявка) отправляется исполнителям на местах. Если заявка настоящая, те ее заводят в базе (где, по идее, и должен генериться пароль при заведении нового заявителя) процесс разорван во времени. а мне то надо тому человеку, что отправил заявку, уже отдать логин и пароль, чтобы он мог контролировать процесс ее продвижения.
Как быть?
подскажите, плиз!!!!

edges7Придумывать ничего не нужно. Все это уже придумано до вас. :)
Посмотрите книжицу: Томсон Л., Веллинг Л. - "Разработка Web-приложений на PHP и MySQL". Там вопросы связанные с регистрацией и авторизацией пользователей рассмотрены довольно подробно. Со всеми примерами. Книга в интернете есть.


Всё бы хорошо, если бы база была сразу на my-sql.
А у меня она постоянно выкачивается с другой базы (не вэб).
В которой я не собираюсь заводить как пользователей пользователей-интернет.
Там строго ограниченное кол-во специалистов с ней рабротают. Поэтому там пароли и логины - это всего-лишь заявители. Вся проблема в интеграции этих 2х баз

edges7 Стаська В которой я не собираюсь заводить как пользователей пользователей-интернет.


Их там и не нужно заводить. Для этого будет достаточно БД MySQL, с которой будут работать интернет-пользователи. Просто рисуете Web-странички, где ваши "заказчики" будут регистрироваться, аутентифицироваться, делать заказы. Т.е. делаете что-то вроде простой системы приема заказов. На свой стороне, вы проверяете полученную информацию и т.д. По проишествии какого-то времени перегоняете уже достоверную информацию из MySQL в вашу локальную БД. И уже там делаете отчеты и проч.

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

И на сайте пароль. Но фишка в том, что на сайте заведенный пользвователь еще не присутствует в локальной системе.
Как потом это все синхронизировать??

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

Ну и какая разница, где будет регистрироваться заявка? Один клиент зашел на ваш сайт, зарегистрировался/аутентифицировался - сделал заказ. Другой пришел к вам в организацию. Менеджер открыл страничку с регистрацией пользователя или какую-нибудь там специальную форму - зарегистрировал пользователя, выдал пароль, зафиксировал заказ. Все данные в обоих случаях хранятся в одной БД. В данном случае в MySQL. Завтра этот же пользователь зайдет на ваш сайт, авторизуется, снова сделает заказ. Т.е. все данные хранятся в MySQL и первоначально обрабатываются на web-сервере. Ну а потом в зависимости от ваших задач перегоняйте данные в вашу локальную БД.
P.S. А вообще приобретите новое железо и не парьтесь.

разница в том, что у менеджеров (у доброй половины) отключен доступ в интернет (такая политика у предприятия). поэтому пароль никак не может им быть сгенерирован в mysql!
Он им может быть сгенерирован толлько в другой базе. таая вот раздвоенность! Вот!

Стаська edges7[quot Стаська]Т.е. все данные хранятся в MySQL и первоначально обрабатываются на web-сервере. Ну а потом в зависимости от ваших задач перегоняйте данные в вашу локальную БД.
P.S. А вообще приобретите новое железо и не парьтесь.

разница в том, что у менеджеров (у доброй половины) отключен доступ в интернет (такая политика у предприятия). поэтому пароль никак не может им быть сгенерирован в mysql!
Он им может быть сгенерирован толлько в другой базе. таая вот раздвоенность! Вот!

Нет! Нет! Нет! Данные на web - это СОВСЕМ не первоначальные данные. Эти данные вторичны и частично берутся из лок.БД, чтобы заказчики могли ознакомиться с движением своего заказа.
Нито из менеджеров не собирается работать с web -базой. она просто добавлена для увеличения способов подачи заявок. основная работа ведется на местах. (Это не интернет-магазин)

cyxedges7

Тут действительно проблема концептуальная и книжица не поможет. )

Стаська

Похоже, что в вашем случае надо идти от задачи. А вы излагаете красочно, эмоционально, но, мягко скажем, не однозначно.
авторЭто не интернет-магазин
Слишком мало информации, увы. Если добавите конкретики, то что-то удастся посоветовать, я просто уверен...

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

Так.... попытаюсь сформулировать (хотя тяжелово формулировать то, концепция чего у тебя у самой еще не созрела).
Имеется база MS-SQL. На ней крутится БД предприятия. Бд большая по объему (около 16 Гигов). Большинство данных из нее не предназначена для широкого публикования.
К предприятию обращаются заявители (в базе я их зову "партнеры"). У них там есть отдельная бооооольшая таблица. Они оставляются свои заявки (тоже таблица), которые дальше обрабатываются, и попутно в базе созлдается куча объектов.
Предприятие разнознено по городам (а не три комнаты на одной площадке). Не во всех филиалах есть доступ в интернет, но везде есть корпоративная почта.
Еще у предприятия есть web-сервер, к которму мы не имеем отношения и распоряжаться там не можем!
Так вот, в светлые головы руководства пришла идея сделать так, чтобы заявку можно было подавать и с интернета.
Но я не могу присоединить эту базу к интернету. По ней такой объем данных гоняется, что она просто сдохнет (особенно,если кто-н. изобразит с интернета DoS-атаку). Да и страшно как-то.
К тому же на их web-сервере стоит линукс и my-sql, так что об MS-SQL и речи не идет!
Поэтому из нашей базы будет джобом периодически будут выкатываться партнеры-заявители (но все данные, а типа квери). Думаю, ту базу проинициализировать логинами и паролями для входа на сайт, чтобы они с сайта могли следить за движением заявок. а в my-sql подавать логин и хэш пароля? (жаль только ,в MS вроде нет скл-кой функции для хэша, еще проблемка, блин.)
Но они могут подать заявку и через сайт.....
И там получить логин и пароль. И там завести данные о себе. И свою заявку (туда включаются и бинарные файлы). С уменьшенным набором полей. А мне эти данные надо передать в MS.
Но сливать их в базу я не могу. (Каждые данные сначал должны пройти проверку на их подлинность), поэтому заявка будет просто рассылаться письмами по корпоративной почте. Но мне же потом надо синхронизировать все логины и пароли? Да и как-то пометить сгуженные данные, чтобы повторно их не выгрузить
И если я им там дам пароль, мне его надо синхроизировать же!!! (да и вопрос, в каком виде его хранить??)
Сначала хотела сгружать заведенных партнеров в базу, а вот теперь думаю, вдруг там будет много спама. А базу загаживать???ъ
Короче, примерно так. Да там еще много проблем. Может, кто с подобныим хзаджачами сталкивался?

Petro123 Стаська
Не во всех филиалах есть доступ в интернет, но везде есть корпоративная почта.

===== значить написать им клиента и договориться с админами по открытию одного порта для отправки заявки (хоть в excell, хоть о модему). Так делает сеть аптек со своими клиентами-аптеками.

Еще у предприятия есть web-сервер, к которму мы не имеем отношения и распоряжаться там не можем!

== и web программистов тоже нет

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

===== при отсутствии доступа к интернету выше?

Но я не могу присоединить эту базу к интернету.

== и правильно




Заявку-то с интернета подают пользователи-заявители. Чтобы не ходить в предприятие. А интернета нет у предприятий.
На счет аптек не поняла.
Т.е. просто заявка сплошным текстом, а на местах ее пусть работники вбивают?

cyx авторПроблема заключается в авторизации пользователй.
дело в том, что информацию могут смотреть "заявители" из сетевой базы. на местах им выдают логин и пароль для входа на сайт
кто на ком стоял? (с)
что значит смотреть сайт из сетевой базы, а главное, зачем?

Вы упорно не хотите рассекретить предметную область, поэтому приходится играть в угадалки...
Для выполнения заказа заявитель=партнер должен явится на фирму (в филиал)? Понятие оплаты заказа существует в вашей модели? Заказ через сайт - это АЛЬТЕРНАТИВА или некая экономия времени. дающая возможность часть обработки заказа перевести в оффлайн (разгрузить очередь в конторе, не более того)?

Через сайт - идея руководства. Хотят предроставть возможнойсть заявителю подавать заявки разными способами, чтобы "круто было", и филиалы несколько разгрузить от заявителей.
Хотя основоной способ подачи заявки - ножками прийти и филиал и подать заявку.

Petro123а это как понимать?
Стаська
Не во всех филиалах есть доступ в интернет, но везде есть корпоративная почта.


Ну так и понимать.
Почта корпоративная есть везде
(что-то типа bla-bla@korporativ.ru).
А интернет не везде.
Почему так - я не знаю.
Администрированием занимается СООВСЕМ другая организация. Это просто факт такой.