stells2Да, действительно, вам лучше самому сходить в поликлинику и взять интервью в той же регистратуре.

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

Только потом. Повторяю, потом уже создаётся модель данных. Так как на это влияет огромное множество факторов.

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

Wlr-lТипичный программистский подход к решению системных задач.

Эмм.. ну да

Вы когда придёте к врачу, он начнёт вас лечить как доктор, а не как финансовый аналитик, вы ему тоже скажете "типичный врачебный подход к решению задач"??

Насмешили, право ))

Wlr-lКак раз, наоборот, для создания модели данных нужно выявить базовые (системообразующие) факторы, слабо влияющие на предмет автоматизации с течением времени. Например, "Карта амбулаторного больного" будет базовым фактором, а списки, определяющие внешний вид программы не являются базовыми, следовательно, не входят в модель данных. Модель данных, ну совсем, не должна определяться пользовательским интерфейсом. Завтра заведующей поликлиникой станет "тетя Маша" и отшлифованный при "тете Вере" пользовательский интерфейс окажется совсем не отшлифованным! А данных накоплено уже не мало...

Эта информация появилась после общения с девочкой, сидящей в регистратуре?



Wlr-lКак уже говорили, данные и базы данных живут дольше программ.

Данные вообще-то жили и до программ, и "живут" даже без программ. Информационное пространство простирается за пределы информационный программных систем, представляете? Вот это нонсенс!

Wlr-lПрограммы можно менять, скажем, как перчатки.

Какое прекрасное и наивное во всех смыслах абсолютно заблуждение

Wlr-lС базой данных, просуществовавшей некоторое время, это сделать намного сложнее.

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

Wlr-lЯ бы сказал, что база данных это базис, а программы, работающие с ней, это надстройка. Прямо политэкономия получается...

Это очень странно, когда кто-то сравнивает программы с данными. Вы ещё снег и лыжи сравните, ведь вроде как лыжи это тоже надстройка )))


Wlr-lСогласен, для этого нужен классический треугольник: руководитель - исполнитель - системотехник. Оставьте любые два угла и у вас ничего не получится. Самая большая беда, когда в качестве системотехника выступает программист. Вопросы выявления базовых факторов уйдут в споры о классах, наследовании, ОРМ, мой язык программирования решает это за один оператор, а в вашем языке программирования нужно написать пять строчек...

Я всего лишь сказал о том, что пообщаться с персоналом недостаточно, чтобы потом пойти и начать моделировать базу данных. :)

Wlr-lВ результате "программистского подхода" системы с БД становятся все тяжеловеснее и тяжеловеснее, запросы работают все дольше и дольше. Один мой коллега говорит, что его база данных (Foxpro) занимала 20 Гб, то новая (SQL), с теми же возможностями, уже требует более 600 Гб. Работа, которой требовалось максимум 20 минут, уже не может быть выполнена за одну ночь. Есть иерархии классов, но нет модели данных. А ты все про лыжи...

Ну ясн. Раньше и трава была зеленее и колбаса вкуснее.

982183А "интерфейс" и отчетность это единственное что они смогут вменяемо объяснить.

Вообще, только отчётность. И то, потому что она у них есть на руках.