Прием-регистрация заявок. Подскажите технологию

  • Автор темы Vinz
  • Дата начала
V

Vinz

#1
Здравствуйте, уважаемые!
В общем возникла такая проблема: необходимо разработать небольшую систему для приема-регистрации заявки клиента.

Т.е. Существует сайт фирмы, на сайте расположена форма заявки, которую заполняет клиент. Заполненная заявка (десяток строковых переменных) сохраняется в БД на сервере. Менеджер с помощью программы-клиента подсоединяется к сайту и скачивает новые заявки на локальную машину (перенос из БД на сервере в локальную БД).

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

Kmet

Java Team
25.05.2006
1 036
8
#2
какую лучше знаете ту и используйте. в вашем случаю все современные технологии предоставляют нужный интрументарий
 
V

Vinz

#4
2 etc

Существует сайт фирмы
Где он хостится?

Цитата(Vinz @ 12:01:2009 - 08:24) *
сохраняется в БД на сервере
Что за бд?
хостинг регистрировался через наш Новосибирский провайдер (http://54.ru), на хостинге стоит веб-панель администрирования Plesk 7 Reloaded

я описал общий принцип, который необходимо реализовать. на данный момент существует только сайт фирмы. То есть мне нужно реализовать передачу заявки клиента на локальную машину менеджера... "сохраняется в БД на сервере" - это то, как я понимаю принцип реализации этой задачи...
вообще БД думал делать на SQL
 
E
#5
Vinz Ваши "думал" и т.д не очень интересны. надо точно знаьт т.к. хостинг определяет многие вещи. Ну например даст ли он прямой доступ к бд или нет, какая субд в вашем плане, т.к. тоже может наложить ньюансы, хотя и врядли.

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

Да и - Kmet #2 - тоже со счетов нельзя скидывать.

вообще БД думал делать на SQL
Такой субд нету и небыло никогда!
 
V

Vinz

#6
вообще БД думал делать на SQL
Такой субд нету и небыло никогда
планировал делать БД с использованием СУБД MySQL.

Спасибо, все замечания я учту... Но мне бы хотелось узнать КАК реализовать поставленную передо мной задачу. Принцип как это лучше сделать. Поскольку сам не совсем понимаю, вот и прошу помощи :ph34r:
 
E
#7
Принцип как это лучше сделать.
Вот опять вы ... да при чем тут "как лучше" ... какая есть возможность так и делать!!! все ваши "как лучше" могут полететь как миленькие, стоит только хостеру сказать - "идите лесом с вашим лучше", а уж он может, и не сомневайтесь.

Смотрите у вас данные находяться на сервере (неважно на сколько) далеко. Вам надо их вытянуть к себе на машину.
Есть несколько способов это сделать, но все они зависят от того, есть ли у вас определенные условия для каждого.
Допустим, ваш хостер оч. хороший и как тока вы его попросили дать доступ в вашу базу, он тутже согласился, создал вам пользователя специального, и дал вам аккаунт, и порты и т.д. Тогда нет проблем вы пишите простую программку (неважно на чем) и все так чинно и благородно.
Но вот он не такой хороший, и на вашу просьбу он вам скрутил такую "фигуру" которую вы отродясь не видели (а такой поворот - 95% случаев). И тогда вам надо придумывать еще кокогото посредника, кто вам даст всетаки доступ к вашимже данным. Ну например сфарганить веб-сервисов и кинуть их рядом с базой. Тогда возникает еще вопрос, как и на чем их делать. Ну судя по отстойности выбранной вами субд, то это будет пыхпых, не иначе :ph34r:.

А вот интересно, а чем вам не устраивает веб интерфейс. т.е. зачем обязательно - "перенос из БД на сервере в локальную БД"?

И ваще - "как лучше" - аморфная субстанция (о как завернул, беззсмысла но красиво :)), т.к. сення одно лучше завтра другое, а еще говорят, "что русскому хорошо, то немцу - кранты", это из тойже оперы ... "как лучше" всегда идет в контексте.
 
V

Vinz

#8
какая есть возможность так и делать
:ph34r: хорошо, что посоветуете? как узнать какая же возможность есть?

Ну судя по отстойности выбранной вами субд
посоветуйте! а то я ничего конкретного так и не услышал... А то Вы все говорите на какие грабли я могу наступить, а вот что мне предпринять чтобы этого избежать?

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

Kmet

Java Team
25.05.2006
1 036
8
#9
Ну судя по отстойности выбранной вами субд
отличная бд для своего сегмента.

потому что доступ в интернет по модемной связи, то есть раз в день соединился - получил - разъединился, а с данными будут осуществляться десятки операций, которые необходимо будет в дальнейшем реализовать... но сейчас меня это мало интересует
в любом случае выставлять бд на ружу - это не дело. пишите гейт, который при соединении, будет заявки зипованым xml
 
E
#10
хорошо, что посоветуете? как узнать какая же возможность есть?
Так обратиться к хостеру и спросить, что он может дать.
Тут можно посоветовать, только после того как вы будете знать, иначе это гадание, бестолковое занятие.
По поводу субд и т.д. - опять же, все зависит от вас и хостинга. Смотря что он может и что вы можете.
Посоветовать можно лишь на ориентацию в направлении "нормальных" - "класса энтерпрайз", например MS SQL Server, Oracle, PostgreSql и т.д. MySQL не из этого ряда. :(
При наличии нормальной базы, можно было-бы организовать синхронизацию данных по средствам репликаций - еще один способ. Чем хорошо - тем что, и писать ничего ненадо, например при MS SQL Server (про другие я не совсем в курсе) это все делаеться административными делами (настройками), т.е. вы вышли в инет, запустили репликацию, и опа - данные уже в вашей базе, но опять же - все зависит от конкретных условий.
потому что доступ в интернет по модемной связи
А, ну тогда это понятно.

в любом случае выставлять бд на ружу - это не дело
Докажите.
 

Kmet

Java Team
25.05.2006
1 036
8
#11
Посоветовать можно лишь на ориентацию в направлении "нормальных" - "класса энтерпрайз", например MS SQL Server, Oracle, PostgreSql и т.д. MySQL не из этого ряда. smile.gif
докажите
ри наличии нормальной базы, можно было-бы организовать синхронизацию данных по средствам репликаций - еще один способ. Чем хорошо - тем что, и писать ничего ненадо, например при MS SQL Server (про другие я не совсем в курсе) это все делаеться административными делами (настройками), т.е. вы вышли в инет, запустили репликацию, и опа - данные уже в вашей базе, но опять же - все зависит от конкретных условий.
google it mysql replication
противоречите сами себе.
Цитата(Kmet @ 13:01:2009 - 11:30) *
в любом случае выставлять бд на ружу - это не дело
Докажите.
хотя бы google it dbname exploit
 
E
#12
противоречите сами себе.
Где? где я сказал что с MySQL этого нельзя?
то, что с нормальными можно а она не такая? тогда я неправильно выразился, минус мне, да и "не верю" я их репликации, а более плотно с ней знакомиться нету желания ни времени ... ;)
И что это доказывает? Да и ваще что за манера ... чет нашли, ок - к гуглу прикрутите конкретную ссылку по которой можно понять, что да, действительно всем капец наступит "в любом случае". А пока, бум считать - бездоказательно. :p

Kmet Коли вы знаток MySQL, расскажите в чем был сокральный смысл всей чехорды с ее инжинами, типа иннодб и т.д. нафик все это было сделано?
Мне не много приходилось работать с ней. но постоянно прикалывало это вот, да и с навернули с колэйшинами, опять же только запутали всех.
Постоянно по инету слышны непонятки по отношению к этому. Недавно надо было тоже вот так, настроить механизм синхронизации.
У нас был MS SQL Server а на другой стороне MySQL, блин почти день промаялись, чтоб скрестить ... то то ей нетак, то это не этак ... в итоге конечно настроили, но это все похоже на пляски с бубном, нежели на нормальный процесс.
В итоге у меня к ней крайне негативное отношение. :(
 

Kmet

Java Team
25.05.2006
1 036
8
#13
И что это доказывает? Да и ваще что за манера ... чет нашли, ок - к гуглу прикрутите конкретную ссылку по которой можно понять, что да, действительно всем капец наступит "в любом случае". А пока, бум считать - бездоказательно. tongue.gif
вполне себе весомы аргумент. субд пишут не боги. эксплойты к ним появлялись и будут появляться. чем меньше интерфейсов выставляется наружу тем спокойнее живется и легче подерживаться. в особенности если бд хостит третья сторона. кто ж знает на сколько оперативно админ хостера патчит бд. плюс лишняя зависимость клиентского кода. вы что привели в поддержу своего мнения.

Kmet Коли вы знаток MySQL, расскажите в чем был сокральный смысл всей чехорды с ее инжинами, типа иннодб и т.д. нафик все это было сделано?
Не вижу ничего плохого в нескольких энджинах за одним интерфесом. не хочешь разбираться - берешь самый современный, есть специфические требования - выбираешь наиболее подходящий. Опять же обеспечивает обратную совместимость.
да и с навернули с колэйшинами, опять же только запутали всех.
никогда не мешало
остоянно по инету слышны непонятки по отношению к этому
не знаю что там слышно в инете - не слежу.
У нас был MS SQL Server а на другой стороне MySQL, блин почти день промаялись, чтоб скрестить ... то то ей нетак, то это не этак ... в итоге конечно настроили, но это все похоже на пляски с бубном, нежели на нормальный процесс.
то что вы не осилили, еще ничего не доказывает. интеграция продуктами мс частенько вызывает трудности, политика они что ли такая...

в сухом остатке мы имеем, что мускл это одна из самых распростаненных бд + замечена в ипользовании в таких проектах как ютуб и линкедин.
а неготивное отношения надо высказывать именно как личное отношения, а не как истину последней истанции
 
E
#14
вы что привели в поддержу своего мнения
А я также как и вы скажу, что - ну и что? осы тоже не без дыр, и че, не юзвть чтоли? короче не аргумент, сааавсем ...
Не вижу ничего плохого в нескольких энджинах за одним интерфесом.
Я не спрашивал про что там видно плохого или нет, я инетересовался в чем соль их, а уж совместимость и тем более обратная ... кхм, тут както совсем никак.
когда не сталкивался, тоже не мешало
не знаю что там слышно в инете - не слежу.
Хватит и туташних.
интеграция продуктами мс частенько вызывает трудности
И пошла вода на мс ... дальше не интересно.
в сухом остатке мы имеем
У каждого свой остаток, мы с альфа-центавры и имеем другую информацию. (с почти гостья из будущего :unsure:)
 
V
#15
Спасибо, уважаемые :unsure: я услышал более или менее конкретное направление действий :) будем разбираться дальше, а там посмотрим ;)