|
|
|
субд "расписание поликлиники"
|
|||
|---|---|---|---|
|
#18+
Доброго времени суток. Поступил тут заказ на систему онлайн-записи на приём. Предполагается 2 сервера: основной - в поликлинике, куда будет вноситься вся информация о всех приёмах (с сайта-автоматом и из регистратуры) и с которого будут выводиться отчёты и, возможно, бухгалтерские документы. Второй - веб-сервер, к которому имеют доступ простые пациенты и агенты страховых компаний, основная его задача - отображение пустых позиций в расписании и пациентов данной страховой компании. Ну и репликация между ними. Число пациентов - до 1200 в день. В БД одна сводная таблица (расписание) и несколько редко обновляемых таблиц-справочников. Так вот в связи с этим возникает вопрос к уважаемым разработчикам: справится ли с поставленной задачей среда mysql+php+apache на обоих серверах (в плане производительности)? Какие тут примерно требования к железу? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2007, 12:53 |
|
||
|
субд "расписание поликлиники"
|
|||
|---|---|---|---|
|
#18+
JonnywalkerТак вот в связи с этим возникает вопрос к уважаемым разработчикам: справится ли с поставленной задачей среда mysql+php+apache на обоих серверах (в плане производительности)? Какие тут примерно требования к железу?Может справится, а может нет. Есть системы, построенные на MySQL, которые и большее кол-во обращений выдерживают. А есть системы (на том же MySQL) которые и при одном пользователе тормозят. Здесь зависит много от внутренней архитектуры самой системы. От структуры таблиц, от того какие запросы будут выполняться. Настораживает то, что будут какие-то бухгалтерские проводки в системе. Бухгалтерия - это такое дело, что с ней и "взрослые" СУБД не ахти как справляются. Так что - сперва подумать, прикинуть, а потом выбор инструментария. Тесты, в конце концов провести можно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2007, 13:40 |
|
||
|
субд "расписание поликлиники"
|
|||
|---|---|---|---|
|
#18+
а нафига 2 сервера и гемморой с репликацией ? как я понял юзеров от силы пару десятков, т.е. достаточно одного entry level сервочка. mysql справится, но я бы поставил что-то, посерьезней где есть вложеные селекты и т.п. типа postgres, oracle xe и т.п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2007, 13:49 |
|
||
|
субд "расписание поликлиники"
|
|||
|---|---|---|---|
|
#18+
JonnywalkerДоброго времени суток. Поступил тут заказ на систему онлайн-записи на приём. Предполагается 2 сервера: основной - в поликлинике, куда будет вноситься вся информация о всех приёмах (с сайта-автоматом и из регистратуры) и с которого будут выводиться отчёты и, возможно, бухгалтерские документы. Второй - веб-сервер, к которому имеют доступ простые пациенты и агенты страховых компаний, основная его задача - отображение пустых позиций в расписании и пациентов данной страховой компании. Ну и репликация между ними. Число пациентов - до 1200 в день. В БД одна сводная таблица (расписание) и несколько редко обновляемых таблиц-справочников. Так вот в связи с этим возникает вопрос к уважаемым разработчикам: справится ли с поставленной задачей среда mysql+php+apache на обоих серверах (в плане производительности)? Какие тут примерно требования к железу? 1200 обращений в день/24 часа/60 минут < 1 обращения в минуту!!! Легко справится... Мнения по поводу реализации: 1. Если таки стоит задача разделить Web-интерфейс и сервер БД, то можно сделать один сервер Appache+php, а на втором сервере (в поликлинике) развернуть MySQL. Из php-скрипта идет коннект на сервер БД. Если коннекта нет, то сразу "вываливать" клиента сообщением о недоступности сервиса... У нас есть система, которая организована так же, правда работает только во внутренней сети предприятия и вместо MySQL стоит полноценный Oracle... Кроме того, при едином сервере БД сразу решится проблема коллизий репликации (которые будут в Вашем варианте при отсутствии и дальнейшем восстановлении связи), когда несколько клиентов с разных серверов БД будут претендовать на одного врача на одно время приема... 2. Присоединяюсь к мнению, что MySQL несколько несерьезно для такой системы... Но уж если сердце лежит к MySql, то надо использовать версию >=5.0, так как хранимые процедуры - " it's cool !!! " ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2007, 14:29 |
|
||
|
субд "расписание поликлиники"
|
|||
|---|---|---|---|
|
#18+
Возникает ещё вопрос: где лучше развернуть сервер БД - в самой поликлинике или взять выделенный в аренду вместе с хостингом? в первом случае имеем: +++более быстрый коннект с базой для внутренней обработки данных ---возможные тормоза в работе всего сайта из-за обрыва инета (и моё личное предубеждение, что внуктрикорпоративные данные лучше хранить внутри фирмы :) во втором случае имеем: +++быстрый коннект сайта с базой, 2\3 из этих 1200 пациентов проходят через страховщиков (несколько десятков пользователей), которые работают с базой через сайт + онлайн-запись одиночников. ---На случай обрыва инета можно делать регулярный односторонний бэкап с сайта в поликлинику, чтобы не прерывать работу учреждения, но прекращать запись из поликлиники. ---С опозданием принимаем новые записи с сайта во время обрыва связи (и предубеждение начальства о том, что сервер на хостинге по определению обеспечивает большую надёжность и бесперебойность в работе :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2007, 15:27 |
|
||
|
субд "расписание поликлиники"
|
|||
|---|---|---|---|
|
#18+
А бухгалтерия предполагается типа документов по форме на печать, не более. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2007, 15:31 |
|
||
|
субд "расписание поликлиники"
|
|||
|---|---|---|---|
|
#18+
JonnywalkerВозникает ещё вопрос: ... предубеждение начальства ну правильно, вы сможете обеспечить в поликлинике отдельную закрываемую на ключь комнату оснащенной кондиционером, спец. пожарной системой, с упсами и дизель-генераторами плюс дублирование инет канала ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2007, 15:44 |
|
||
|
субд "расписание поликлиники"
|
|||
|---|---|---|---|
|
#18+
Yo.! mysql справится, но я бы поставил что-то, посерьезней где есть вложеные селекты Где-то с 4-й ветки они есть и в mysql. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2007, 15:54 |
|
||
|
субд "расписание поликлиники"
|
|||
|---|---|---|---|
|
#18+
Yo.! JonnywalkerВозникает ещё вопрос: ... предубеждение начальства ну правильно, вы сможете обеспечить в поликлинике отдельную закрываемую на ключь комнату оснащенной кондиционером, спец. пожарной системой, с упсами и дизель-генераторами плюс дублирование инет канала ? давйте теперь все внутрикорпоративные данные всех корпораций повесим на провайдеров! Здесь надо думать следующим образом: - сколько людей обратится по Инету и через регистратуру. ИМХО, основной поток пойдет через регистратуру. Поэтому ее работу останавливать никак нельзя. - кому on-line данные нужнее: регистратуре "на месте" или пользователям Инета? Поэтому, мое ИМХО - сервер БД должен быть в поликлинике. И исключительно в поликлинике. И если человек не смог "достучаться" до БД через сайт, то пусть он идет... в поликлинику! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2007, 15:57 |
|
||
|
субд "расписание поликлиники"
|
|||
|---|---|---|---|
|
#18+
Задача всего этого стоит следующая: разгрузить телефон регистратуры. Сейчас 2\3 пациентов записываются по телефону через страховые компании, которые опять же по телефону связываются с поликлиникой, уточняют наличие мест, а потом подтверждают запись или предлагают другое время. После реализации проекта: пациенты звонят в страховые компании (их несколько десятков). Оператор компании через привелегированный доступ на сайте проверяет наличие мест и сразу записывает пациента. 1\3 пациентов-хозрасчётники, записываются либо по телефону, либо в поликлинике (что опять ведёт обращение оператора поликлиники к сайту) либо сами через сайт. Но с другой стороны, каждая запись в расписании по факту исполнения или неисполнения должна быть отмечена администратором из поликлиники и доступна для страховых компаний. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2007, 16:14 |
|
||
|
субд "расписание поликлиники"
|
|||
|---|---|---|---|
|
#18+
Станислав С...кий давйте теперь все внутрикорпоративные данные всех корпораций повесим на провайдеров! ну если корпорации настолько бедны, что не могут у себя содержать нормальную серверную то другого варианта нет ... гораздо проще обеспечить в полеклинике 2-3 инет подключения, чем там пытатся защитить сервер от бабки со шваброй. >Где-то с 4-й ветки они есть и в mysql. разве 4й такое умеет: selet * from (select * from table ) where ... ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2007, 16:47 |
|
||
|
субд "расписание поликлиники"
|
|||
|---|---|---|---|
|
#18+
mysql 4.1.16-max - работает, прверено. Кажется, оффтопик пошёл... Хотелось бы ещё услышать советы по теме старших и опытных товарищей ))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2007, 17:07 |
|
||
|
субд "расписание поликлиники"
|
|||
|---|---|---|---|
|
#18+
JonnywalkerЗадача всего этого стоит следующая: разгрузить телефон регистратуры. Сейчас 2\3 пациентов записываются по телефону через страховые компании, которые опять же по телефону связываются с поликлиникой, уточняют наличие мест, а потом подтверждают запись или предлагают другое время. После реализации проекта: пациенты звонят в страховые компании (их несколько десятков). Оператор компании через привелегированный доступ на сайте проверяет наличие мест и сразу записывает пациента. 1\3 пациентов-хозрасчётники, записываются либо по телефону, либо в поликлинике (что опять ведёт обращение оператора поликлиники к сайту) либо сами через сайт. Но с другой стороны, каждая запись в расписании по факту исполнения или неисполнения должна быть отмечена администратором из поликлиники и доступна для страховых компаний. А поликлиника получается не муниципальная да? Странная какая-то схема записи на прием: пациент->страховая->поликлиника.....:) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2007, 13:19 |
|
||
|
субд "расписание поликлиники"
|
|||
|---|---|---|---|
|
#18+
Нет, не муниципальная. В муниципальных и печать номерков - дело неслыханное, врачи сами краску для единственного принтера покупают((( Не то, что онлайн-запись((((( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2007, 14:05 |
|
||
|
субд "расписание поликлиники"
|
|||
|---|---|---|---|
|
#18+
По архитектуре. Из соображений доступности и безопасности сервер БД следует установить непосредственно в поликлиннике. Web сайт для внешних посетителей проще всего захостить у провайдера, это позволит обмениваться с БД только теми данными, которые по разным причинам нельзя хранить удалённо. При обрыве связи с БД клиент найдёт на сайте разумное объяснение происходящего и варианты решения проблемы, например № телефона регистратуры. Кроме того на сайте могут присутствовать другие сведения (реклама, статьи, инструкции и т.п.), которые не нужно хранить в БД. Для внутреннего пользования седует установить местный Web сервер. Это позволит сотрудникам поликлинники работать с БД по скоростной, защищённой и надёжной локальной сети. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2007, 21:55 |
|
||
|
субд "расписание поликлиники"
|
|||
|---|---|---|---|
|
#18+
mcureenabWeb сайт для внешних посетителей проще всего захостить у провайдера, это позволит обмениваться с БД только теми данными, которые по разным причинам нельзя хранить удалённо. При обрыве связи с БД клиент найдёт на сайте разумное объяснение происходящего и варианты решения проблемы, например № телефона регистратуры. Только не говорите, что будете порт СУБД открывать наружу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2007, 16:05 |
|
||
|
субд "расписание поликлиники"
|
|||
|---|---|---|---|
|
#18+
Нахлобуч mcureenabWeb сайт для внешних посетителей проще всего захостить у провайдера, это позволит обмениваться с БД только теми данными, которые по разным причинам нельзя хранить удалённо. При обрыве связи с БД клиент найдёт на сайте разумное объяснение происходящего и варианты решения проблемы, например № телефона регистратуры. Только не говорите, что будете порт СУБД открывать наружу. Для безопасного доступа с службам СУБД можно использовать разного рода сетевые экраны, частные виртуальные сети, Proxy и проч. технологии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2007, 16:10 |
|
||
|
субд "расписание поликлиники"
|
|||
|---|---|---|---|
|
#18+
все ниже сказанное ИМХО 1. Какая СУБД? Тут вариантов много MySQL, Postgresql, Oracle XE, DB2. Выбор нужно сделать на основе имеющегося опыта команды разработчиков. 2. Где разместить БД? Это должно определяеться бизнесом и экономической эффективностью. Если заказ только на разработку ПО, а законченного решения, то нужно просто определиться будет или нет комплекс поддерживать распределенную БД. 3. Железо Современный сервер начального уровня сможет удовлетворить озвученным запросам. С уважением, bw. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2007, 15:20 |
|
||
|
субд "расписание поликлиники"
|
|||
|---|---|---|---|
|
#18+
BW 2. Где разместить БД? Это должно определяеться бизнесом и экономической эффективностью. Заблудившийся водитель прохожему. -- Простите, где я нахожусь? -- В машине, сэр! Экономическая эффективность достигается вполне конкретными способами. Основная проблема -- понять какими. BW3. Железо Современный сервер начального уровня сможет удовлетворить озвученным запросам. С серверами нужно быть поосторожнее. Сервер должен быть сертифицирован для развёртывания выбранной СУБД. Бывало, что серьёзная СУБД не вставала на сервер начального уровня, хотя нормально работала даже на офисном ПК. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2007, 17:49 |
|
||
|
субд "расписание поликлиники"
|
|||
|---|---|---|---|
|
#18+
mcureenab BW 2. Где разместить БД? Это должно определяеться бизнесом и экономической эффективностью. Заблудившийся водитель прохожему. -- Простите, где я нахожусь? -- В машине, сэр! Экономическая эффективность достигается вполне конкретными способами. Основная проблема -- понять какими. Главный посыл был в том, что если заказ на ПО, то не нужно принимать бизнес-решения относительно эксплуатации. А если заказ на решение, то нужно обсчитать каждое возможное решение. "Что русскому хорошо, то немцу смерть" (с) народная мудрость. mcureenab BW3. Железо Современный сервер начального уровня сможет удовлетворить озвученным запросам. С серверами нужно быть поосторожнее. Сервер должен быть сертифицирован для развёртывания выбранной СУБД. Бывало, что серьёзная СУБД не вставала на сервер начального уровня, хотя нормально работала даже на офисном ПК. Ну не знаю. Впервые слышу, что железку сертифицируют под СУБД. Обычно СУБД сертифицируют под ОС, а уже затем связку ОС и железку. С уважением, bw. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2007, 18:34 |
|
||
|
субд "расписание поликлиники"
|
|||
|---|---|---|---|
|
#18+
BWНу не знаю. Впервые слышу, что железку сертифицируют под СУБД. Обычно СУБД сертифицируют под ОС, а уже затем связку ОС и железку. Ну вот, например, что под руку попалось. Compatibility Matrix ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2007, 19:19 |
|
||
|
субд "расписание поликлиники"
|
|||
|---|---|---|---|
|
#18+
mcureenab BWНу не знаю. Впервые слышу, что железку сертифицируют под СУБД. Обычно СУБД сертифицируют под ОС, а уже затем связку ОС и железку. Ну вот, например, что под руку попалось. Compatibility Matrix Так это несколько иное. Во-первых, см. здесь ;-) Во-вторых, Оракл создал эту программу для набора оборудования для ASM, и к СУБД имеет несколько опосредованное отношение. С уважением, bw. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2007, 20:21 |
|
||
|
субд "расписание поликлиники"
|
|||
|---|---|---|---|
|
#18+
BW mcureenab BWНу не знаю. Впервые слышу, что железку сертифицируют под СУБД. Обычно СУБД сертифицируют под ОС, а уже затем связку ОС и железку. Ну вот, например, что под руку попалось. Compatibility Matrix Так это несколько иное. Во-первых, см. здесь ;-) Во-вторых, Оракл создал эту программу для набора оборудования для ASM, и к СУБД имеет несколько опосредованное отношение. С уважением, bw. Да. А лет 5-6 назад нужно было смотреть список сертифицированного оборудования. Однако в линейке бюджетных серверов Sun серверы пригодные для развёртывания небольших БД специально отмечены, хотя не исключено, что это чисто коммерческий ход... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2007, 15:19 |
|
||
|
субд "расписание поликлиники"
|
|||
|---|---|---|---|
|
#18+
Всем спасибо. Заказчик проанализировал коммерческие предложения и ушёл к старым знакомым разработчикам(((. Что ж, не судьба, пойду дальше сайты клепать... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2007, 17:15 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=34614414&tid=1544420]: |
0ms |
get settings: |
4ms |
get forum list: |
20ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
148ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
61ms |
get tp. blocked users: |
2ms |
| others: | 234ms |
| total: | 486ms |

| 0 / 0 |
