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

Тема в разделе "Свободное общение", создана пользователем Vinz, 12 янв 2009.

  1. Vinz

    Vinz Гость

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

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

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

    Kmet Well-Known Member
    Java Team

    Регистрация:
    25 май 2006
    Сообщения:
    1.018
    Симпатии:
    1
    какую лучше знаете ту и используйте. в вашем случаю все современные технологии предоставляют нужный интрументарий
     
  3. etc

    etc Гость

    Где он хостится?
    Что за бд?
     
  4. Vinz

    Vinz Гость

    2 etc

    хостинг регистрировался через наш Новосибирский провайдер (http://54.ru), на хостинге стоит веб-панель администрирования Plesk 7 Reloaded

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

    etc Гость

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

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

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

    Такой субд нету и небыло никогда!
     
  6. Vinz

    Vinz Гость

    планировал делать БД с использованием СУБД MySQL.

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

    etc Гость

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

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

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

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

    Vinz Гость

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

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

    потому что доступ в интернет по модемной связи, то есть раз в день соединился - получил - разъединился, а с данными будут осуществляться десятки операций, которые необходимо будет в дальнейшем реализовать... но сейчас меня это мало интересует
     
  9. Kmet

    Kmet Well-Known Member
    Java Team

    Регистрация:
    25 май 2006
    Сообщения:
    1.018
    Симпатии:
    1
    отличная бд для своего сегмента.

    в любом случае выставлять бд на ружу - это не дело. пишите гейт, который при соединении, будет заявки зипованым xml
     
  10. etc

    etc Гость

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

    Докажите.
     
  11. Kmet

    Kmet Well-Known Member
    Java Team

    Регистрация:
    25 май 2006
    Сообщения:
    1.018
    Симпатии:
    1
    докажите
    google it mysql replication
    противоречите сами себе.
    хотя бы google it dbname exploit
     
  12. etc

    etc Гость

    Где? где я сказал что с MySQL этого нельзя?
    то, что с нормальными можно а она не такая? тогда я неправильно выразился, минус мне, да и "не верю" я их репликации, а более плотно с ней знакомиться нету желания ни времени ... ;)
    И что это доказывает? Да и ваще что за манера ... чет нашли, ок - к гуглу прикрутите конкретную ссылку по которой можно понять, что да, действительно всем капец наступит "в любом случае". А пока, бум считать - бездоказательно. :p

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

    Kmet Well-Known Member
    Java Team

    Регистрация:
    25 май 2006
    Сообщения:
    1.018
    Симпатии:
    1
    вполне себе весомы аргумент. субд пишут не боги. эксплойты к ним появлялись и будут появляться. чем меньше интерфейсов выставляется наружу тем спокойнее живется и легче подерживаться. в особенности если бд хостит третья сторона. кто ж знает на сколько оперативно админ хостера патчит бд. плюс лишняя зависимость клиентского кода. вы что привели в поддержу своего мнения.

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

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

    etc Гость

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

    Vinz Гость

    Спасибо, уважаемые :unsure: я услышал более или менее конкретное направление действий :) будем разбираться дальше, а там посмотрим ;)
     
Загрузка...

Поделиться этой страницей