Стоимость услуг IT

[Rara_Avis]

Нормализация - процесс творческий. Излишняя нормализация, безусловно вредна. Осложняет написание кода, влияет на скорость выборки (приходится строить постоянно декартовы произведения таблиц, что не есть зер гут с точки зрения быстродействия). Однако недостаточная нормализация может привести к нарушению целостности данных и невозможности получения достоверных отчетов.
Итак: в небольших базах нормализуем все до упора, ортодоксально.
В больших базах - нужен баланс между степенью нормализации и быстродействием.
Пример: как нужно реализовать связь мн-ко-мн? Правильно - через ввод дополнительной, третьей таблицы. Это скажет любой студент. На практике, если мы не будем ее вводить, а сделаем две таблицы, во второй из которых (естественно!), информация будет дублироваться, мы потеряем место на диске (но это всего лишь какая-то пара сотен лишних записей) но офигенно выиграем в скорости за счет индексирования и отсутсвия одного джойна в заппросе. Если в базе миллионы записей, то чего там мелочится с местом на диске?

[Rara_Avis]

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

[Rara_Avis]

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

[Rara_Avis]

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

[Klyk]

Гуд.
вс?таки большинство склоняется к единой таблице справочников.
на мой взгляд тоже сильно упрощает разработку приложения. Как жаль что мне не удалось в этом убедить преподов универа при написании диплома.

[Rara_Avis]

По поводу работы пользователей:
У нас была проблема, что операторы нашей системы в удаленных филиалах заводили одного пользователя несколько раз не утверждая себя проверкой того - был ли этот человек зарегестрирован ранее.
Дело в том, что чтобы избежать накопления народа в приемной (а были такие наплывы), постарались максимально ускорить процедуру. Сделали возможность ввода новых данных "на лету", прямо в списках.
Долго думали, сделали автоматический поиск по ФИО и году рождения. Сделали запрос: "А не тот ли это человек?". Пользователи его прибивали не читая.
Убрали добаление нового ФИО из списка, прилепили рядом кнопку (масюсенькую!) - (+) (Сделать нового).
Пользователи сначала по инерции лезли в список, если не находили нужного человека, то начинали думать.
И что вы думаете?
Наблюдаю картину: сидит тетенка-оператор (не старая) на нашей программе. К ней приходит некто Шульгина и хочет внести деньги. Тетя ищет по базе Шульгину. Не находит.
Береет Шульгу, исправляет ей фамилию на Шульгину и выписывает приходник!
Хорошо что у меня в тот момент не было в руках ничего тяжелого.

Вывод: никакая нормализация не спасет от дурака.

[Rara_Avis]

Гуд.
вс?таки большинство склоняется к единой таблице справочников.
на мой взгляд тоже сильно упрощает разработку приложения. Как жаль что мне не удалось в этом убедить преподов универа при написании диплома.

В нашем биллинге справочники все в одной таблице. А по поводу преподов универа Промолчим.

[Klyk]

Береет Шульгу, исправляет ей фамилию на Шульгину и выписывает приходник!
Хорошо что у меня в тот момент не было в руках ничего тяжелого.

гы....
у меня такое было когда оператор делал документ по расч?ту отпусков.
расчитывали.... потом вс? очищали и расчитывали тут же следующих людей.....

я потом просто на клиентской части закрыл возможность у сохран?нных документов менять контрагента.

[Rara_Avis]

Мы тоже А потом тети наши начали жениться

[Rara_Avis]

В смысле тети из базы...

[Vad]

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

Жолтый писал о подсч?те количества посещений пациентом...
ты будешь искать сколько строк где написано Иванав Иван Иваныч, кторый родился 17.02.1963?
Так Иван Иваныч ходит в больницу каждый месяц, и один раз из 5 посещений больного, работник регистратуры ошиб?тся и пропустит букву 'в' в одном из составляющих им?н. соответственно и точность подсч?та количества посещений будет не верно.


Хм... сделаешь текстоввый ввод например инфы например категорию льгот - "Участник Великой Отечественной войны", код - 02.

Тебя через полгода просят сдлать выборку всех кто имеет эту категорию.
ты в условии запроса будешь писать where field like '%Великой Отечественной%' или что то подобное?
так человек же имеет свойство ошибаться при вводе данных.

А если сделать справочник и связать по ключу, то соответственно и выборка будет точной.

Попробую объяснить.
База талонов должна отражать эти талоны и быть их электронной копией.
К примеру Чел ходил, ходил в больницу с одним адресом, а потом переехал в соседний район.
Если все нормализовать, что получится?
Все его старые талоны в архиве начнут строится с новым адресом, т.к. справочник поменяется.
Чем это черевато? Тем, что исказятся данные, начнутся разборки, появятся мертвые души там,
где их не было и т.д.
получается нужно вводить еще дату изменения реквизита и контролировать ее и так по всем
справочным реквизитам эта задача сама по себе нетривиальна.

Как уже здесь сказали при облегчении ввода ФИО оператор может ввести не ту фамилию
или однофамильца и лучше от этого не будет поэтому обычно делают пару контрольных полей
чтобы выловить такие ошибки.

Один файл справочника не всегда удобен тем, что в справочниках могут содержатся разнородные
данные, кроме того в справочнике может быть не только одно поле данных и один ID, а несколько
полей и индексы также сильно ускоряют работу.
А попробуйте построить простой быстрый индекс по такому справочнику...

[Klyk]

В смысле тети из базы...

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

[Klyk]

Попробую объяснить.
База талонов должна отражать эти талоны и быть их электронной копией.
К примеру Чел ходил, ходил в больницу с одним адресом, а потом переехал в соседний район.
Если все нормализовать, что получится?
Все его старые талоны в архиве начнут строится с новым адресом, т.к. справочник поменяется.
Чем это черевато? Тем, что исказятся данные, начнутся разборки, появятся мертвые души там,
где их не было и т.д.
получается нужно вводить еще дату изменения реквизита и контролировать ее и так по всем
справочным реквизитам эта задача сама по себе нетривиальна.

Согласен, но не вижу ничего не тривиального в контроле дат. тем более не так уж имного нужно в этой области проверять (вот Фамилию на мой взгляд стоит).

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

Один файл справочника не всегда удобен тем, что в справочниках могут содержатся разнородные
данные, кроме того в справочнике может быть не только одно поле данных и один ID, а несколько
полей и индексы также сильно ускоряют работу.
А попробуйте построить простой быстрый индекс по такому справочнику...

Не всегда
например при использовании КЛАДР так не сделаешь
а когда справочники не большие. то можно.

[Rara_Avis]

Попробую объяснить.
К примеру Чел ходил, ходил в больницу с одним адресом, а потом переехал в соседний район.
Если все нормализовать, что получится?
Все его старые талоны в архиве начнут строится с новым адресом, т.к. справочник поменяется.
получается нужно вводить еще дату изменения реквизита и контролировать ее и так по всем
справочным реквизитам эта задача сама по себе нетривиальна.

Ну адрес человека - это не справочный реквизит никак.
Здесь возможен такой выход - в таблице Человеки хранится адрес актуальный, в Талонах дополнительно выписывается по каждому талону. Для оператора - подстановка при заполнениии талона - актуальный адрес.

Один файл справочника не всегда удобен тем, что в справочниках могут содержатся разнородные
данные, кроме того в справочнике может быть не только одно поле данных и один ID, а несколько
полей и индексы также сильно ускоряют работу.
А попробуйте построить простой быстрый индекс по такому справочнику...

Индекс канешна по номеру справочника. Так как справочники традиционно не больно большие, то выборка
Select * from Справочники where НомерСправочника=x
будет работать шустро даже с сортировкой по названию пункта.

По поводу неоднородности справочников - экзотика. Чаще всего имеем поля:
ИД Пункта, НаименованиеПункта, ИндексПункта (целочисл), ДатаСтарта, ДатаЭнда.
Ну и плюс номер справочника, если собирать их в одно табло

[Rara_Avis]

Ну адрес человека - это не справочный реквизит никак.
Здесь возможен такой выход - в таблице Человеки хранится адрес актуальный, в Талонах дополнительно выписывается по каждому талону. Для оператора - подстановка при заполнениии талона - актуальный адрес.

Это обеспечит хранение истории изменения адреса человека. А кстати
ИНСТРУКЦИЯ
ПО ЗАПОЛНЕНИЮ УЧЕТНОЙ ФОРМЫ ? 025-12/У
?ТАЛОН АМБУЛАТОРНОГО ПАЦИЕНТА?
Гласит:
Пункт 8. Вписывается адрес регистрации места жительства по данным паспорта. Заполняется при первом или разовом обращении пациента в ЛПУ.

Вопрос о выборе из трех возможных адресов таким образом снимается
Так что надо к нормативке обращаться, прежде чем что-то проектировать.

[Klyk]

Для оператора - подстановка при заполнениии талона - актуальный адрес.

я бы так сделал это для заполнения по дефаулту.
но возможность выбора бы дал.

[Klyk]

Вопрос о выборе из трех возможных адресов таким образом снимается
Так что надо к нормативке обращаться, прежде чем что-то проектировать.

Посмотри форму N 025/у-04 (не факт что её не придётся печатать этом учреждению)
там два адреса треба.
причём один из них место жительства, который как раз может менятся очень часто.

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

[Rara_Avis]

я бы так сделал это для заполнения по дефаулту.
но возможность выбора бы дал.

Для формы N 025-12/у - я бы не дала менять адрес в самом талоне. Но сделала бы возможность где-то в реквизитах пациента его менять. В конце концов прописка не так уж часто меняется. Зато операторы чего попало не навбивают.

По поводу, того что надо предусмотреть возможность хранения альтернативного адреса - полностью согласна.
Но построить список адресов жительства можно и по предыдущим талонам. Надо только в таблице ТАЛОНЫ заранее завести такую графу. Хранить адрес места жительства в таблице ЧЕЛОВЕКИ не  вижу необходимости. Выносить список адресов по человеку в отдельную таблицу - тоже не считаю нужным. Ничего, кроме проблем при построении запросов и индексации это не даст.

[Klyk]

Для формы N 025-12/у - я бы не дала менять адрес в самом талоне. Но сделала бы возможность где-то в реквизитах пациента его менять. В конце концов прописка не так уж часто меняется. Зато операторы чего попало не навбивают.

Это уже вопросы организации клиента. А тут вопрос дать или не дать решается проще если возможность такая существует.

Но построить список адресов жительства можно и по предыдущим талонам. Надо только в таблице ТАЛОНЫ заранее завести такую графу. Хранить адрес места жительства в таблице ЧЕЛОВЕКИ не  вижу необходимости. Выносить список адресов по человеку в отдельную таблицу - тоже не считаю нужным. Ничего, кроме проблем при построении запросов и индексации это не даст.

возможен и такой вариант.
уже два. что есть гуд.

[Vad]

Бэта версия, со справочниками, отчетами, разделением доступа и т.д.

[Ilya Rudomilov]

которое собственно, и платит тебе.

Подобную фразу слышал недавно от зарубежного заказчика. К сожалению, фраза эта уже была произнесена слишком поздно, чтобы я развернулся и ушел. Фраза сопровождалась высказываниями вроде "Мы тебе платим бешеные деньги и совершенно не понятно, за что". Было охота засунуть им их деньги в задний проход и все это шваброй утрамбовать.
Ситуация была схожая - клиент не знал, чего хотел, но его все не устраивало. В итоге я "показал им кузькину мать", объяснил что такое "американская верстка" и что такое нормальная верстка. В итоге все обиженные разошлись, деньги я получил и с пользой потратил - больше я не хочу с ними общаться.
Если вы платите деньги - это не значит, что исполнитель сделает конфетку, которая вас точно удовлетворит. Нужно уметь объяснить, что вы хотите и прислушиваться к мнению специалиста (если вообще к специалисту вы обратились, а не студенту, который неделю назад изучил пару HTMl-тегов).

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

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

[Klyk]

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

представь себя (можно на ты?) на месте руководителя кампании хотя бы в 2 000 человек. Естественно ты должен значть какой результат должна приносить работа того или иного подразделения.
но воть знать вс? "от и до" тебе нафиг не надо. Для этого как раз и существуют на предприятии разные подразделнеия, в который работают соответствующие специалисты.
К примеру (люблю я примеры)  если ты управляющий банка, зачем тебе знать какие формы отч?тности куда и как надо отправить (а ещ? и вовремя прочитать инструкции по заполнению вновь введ?нной формы), если у тебя для этого есть специально обученые люди, которые этим занимаются.

[Ilya Rudomilov]

представь себя (можно на ты?) на месте руководителя кампании хотя бы в 2 000 человек. Естественно ты должен значть какой результат должна приносить работа того или иного подразделения.
но воть знать вс? "от и до" тебе нафиг не надо. Для этого как раз и существуют на предприятии разные подразделнеия, в который работают соответствующие специалисты.
К примеру (люблю я примеры)  если ты управляющий банка, зачем тебе знать какие формы отч?тности куда и как надо отправить (а ещ? и вовремя прочитать инструкции по заполнению вновь введ?нной формы), если у тебя для этого есть специально обученые люди, которые этим занимаются.

Не думаю, что вы руководите компанией в 2000 человек. И если даже дело так, то тогда разработчики могут обратиться к руководителю отдела, для которого разрабатывается АСУ и он объяснит, что и как должно быть. Вообще, как по-вашему должны разрабатываться АСУ?.. Разработчики должны знать досконально формы отчетности бухгалтерии, отдела кадров и т.д. и т.п.? Понятное дело, что если софтверная фирма специализируется на софте для бухгалтеров, то все разработчики имеют какие-то познания в этой области, а также есть отдельные консультанты, а руководители проектов и вовсе в совершенстве бухгалтерию знают. Но не могут же разработчики знать все науки и сферы жизни!.. Как вы вообще предлагаете разрабатывать АСУ, если сами не знаете, что заказываете?..

[Klyk]

Не думаю, что вы руководите компанией в 2000 человек. И если даже дело так, то тогда разработчики могут обратиться к руководителю отдела, для которого разрабатывается АСУ и он объяснит, что и как должно быть. Вообще, как по-вашему должны разрабатываться АСУ?.. Разработчики должны знать досконально формы отчетности бухгалтерии, отдела кадров и т.д. и т.п.? Понятное дело, что если софтверная фирма специализируется на софте для бухгалтеров, то все разработчики имеют какие-то познания в этой области, а также есть отдельные консультанты, а руководители проектов и вовсе в совершенстве бухгалтерию знают. Но не могут же разработчики знать все науки и сферы жизни!.. Как вы вообще предлагаете разрабатывать АСУ, если сами не знаете, что заказываете?..

Нет, я не руковожу Но я на таком работаю

Не всегда руководитель отдела может дать полную картинку. Он даст много полезной информации. Он расскажет тебе что происходит в его отделе. но документооборот на предприятии на одном отделе не заканчивается. поэтому прид?тся разговаривать не с одним человеком, не с одним начальником отдела а с несколькими и по несколько раз.
Если конечно задача несложная и она работает только в рамках одного отдела,  к примеру: каталог архива документов (кстати, тут руководитель компании вообще может не знать где что и как хранится), то тогда можно и обойтись одним начальником или человеком работающем на этом месете.
Вс? зависит от задачи.

[Vad]

Все зависит от руководителя.
Руководитель может вообще слабо ориентироваться в работе отдела, а заниматся в
основном административными функциями. И тогда все знания порядка работы нужно
узнавать непосредственно у исполнителей.
Бывает ситуация еще хуже, когда и исполнители смутно разбирабтся в том, что
делают. А знают что: "вот эту кнопочку нажать и принтер включить". Это бывает
когда кто-то в отпуске или уволился. И тогда вся нагрузка по пониманию процесса
ложится на АСУ. А если нет АСУ, то на приходящего мальчика Петю, "которого третью
неделю не могут найти".
В этом случае разработчику приходится самому во все вникать и разбираться
лучше, чем непосредственные работники. Таких случаев тоже полно.