Структура программы

Программой обычно называется клиентское приложение, работающее с данными из базы данных. У такого приложения структуры не бывает. Структура бывает у базы данных и её таблиц.
Но я не делю программный продукт на базу и клиентское приложение, а писать собираюсь о том, как придумывается своеобразная структура всего этого вместе.
Эта самая программа (вся вместе) должна содержать информационную копию реальных вещей и процессов и как-то работать с ней. Но обычно в момент возникновения идеи у программиста просто нет достаточного количества информации о той реальности, которая должна быть запрограммирована.
Технические задания не могут решить эту проблему. На лекциях по философии не помню по какому поводу было сказано, что даже такой простой предмет как стул очень сложно описать так, чтобы это могло использоваться например при ревизии. :
 «С четырьмя ножками, спинкой, чтобы сидеть»…- Это трёхногое, куда вы дели стулья?!
Со сложными вещами ещё сложнее. По личному опыту даже техническое задание к конкурсной документации на закупку канцелярских товаров вещь простая (т.е список нужно) только потому, что реально там работают вовсе не официальные механизмы. Никому не придёт в голову писать в техническом задании, что ручки должны быть пишущие, пока не привезут непишущие. А привезут обязательно. Люди не склонны писать очевидные для них вещи. Это только одна причина, по которой механизм технических заданий неработоспособен.
Обычно это делается так. Прикидывается некая начальная структура базы данных (таблицы и поля) в которые, вроде бы, можно вести всю необходимую информацию. Понятно, что это потом может 10 раз поменяться. Что-то будет добавлено, что-то удалено. Но чем лучше удастся угадать с начальным вариантом тем меньше придётся менять (причём серьёзных вещей). Есть легко добавляемые мелочи. Но изменения начальной структуры на стадии когда много написано может означать много изменений во многих местах программы.
В виде этой самой начальной структуры в медицинской конфигурации у меня возникли справочник объектов для хранения всего, что вообще может быть (от симптома «кашель» до лекарства «аспирин»):

И справочник связей объектов:

Этот справочник связей – хранилище всех видов связей, которые могут быть. Кроме составов препаратов тут может быть связь препарат+болезнь (т.е препарат используется при болезни), или весь скелет от объекта «Скелет» (как «Инфекции», «Лекарства») до «кость пальца руки» в качестве «листа» этого «дерева», прицепленная через «ветви» «рука»->   «кисть руки» и связанная типом связи «состоит из».
Тут сразу видна вторая причина, по которой техническое задание типа «хочу» становится сильно урезанным документом. Потому что есть ещё и вопрос «как сделать чтобы это можно было делать?». Если я хочу чтобы машина что-то искала ей нужна информация, которую она будет обрабатывать. Если справочник объектов интуитивно понятен, то справочник связей это уже такое внутреннее чисто машинное приспособление никак не связанное с поставленной задачей, но необходимое.
Я всё ещё понятия не имею, что и как будет в этих таблицах хранится. Но я прекрасно понимаю, что справочник, в котором хранится вообще всё потребует и хранения разнообразной информации, касающейся конкретных строк – объектов.
Чтобы было куда вводить эту информацию я сразу цепляю к таблицам замечательный 1С-овскй инструмент «Характеристики»:
http://akostina76.ucoz.ru/blog/2016-10-15-3515

Причём цепляю я его сразу ко всему, что только может быть:

Я не знаю, что из этого потребуется. Только большой объем введённых реальных данных сможет дать ответ на вопрос, что из этого будет нужно, а что нет. Но пока а снимаю тут сразу все ограничения и даю возможность ввести разнообразную поясняющую информацию к чему угодно.
Ещё я понимаю, что справочники имеют все шансы стать очень большими. Есть объемы информации, при которых начинает задумываться машина. Человеку становится неудобно работать с информацией намного раньше. Присутствующие везде поиски по подстроке частично снимают проблему, но всё равно задача явно требует более серьёзного подхода к этой проблеме. Всё будет работать и без этого. Для формальной работоспособности достаточно правильной структуры информации, т.е возможности ввода данных и поиска по ним. Вопрос только в том сколько человеческого времени потребуют эти действия.
Пусть я например ввожу описания препаратов. Если я занимаюсь конкретно этим (т.е в тот день, когда я занимаюсь конкретно этим) мне вообще нужно видеть из всего справочника только несколько разделов. Пусть меня интересует только взаимодействие инфекции и лекарств. Тогда все остальные строки только мешают и отвлекают внимание. Я могу настроить вид справочника так:

Это тоже стандартная 1С-овская настройка формы:

Но есть одна хитрость: в базе храниться только «Родитель» конкретного объекта. Чтобы сразу по объекту узнать «корень» или первую «ветку» дерева, к которому прицеплена информация много чего надо сделать. Настройки формы этого не умеют. Потому и появились специальные внутренние поля «Родитель1» и «Родитель2» заполняемые автоматически при вводе информации. Для любой бактерии выше) в Родитель1 = «Инфекции» а Родитель2 = «Бактерии». Эти автоматически заполняемые дополнительные поля позволяют дальше пользоваться уже настройками форм 1С.
Там есть вторая настройка с тоже хитрим автоматическим заполнением, позволяющим отметить галками какие-то строки как часто нужные и работать только с ними. Кроме всем известных бактерий есть ещё грибы и внутриклеточные организмы, на которые стандартные антибиотики не действуют. Пусть мне зачем-то именно это потребовалось, а выбрать эту информацию выбором групп невозможно. Тогда мне достаточно отметить нужную информацию, с которой я собираюсь сегодня работать галками и справочник станет почти пустым при просмотре:

На самом деле пока с этим работать неудобно потому, что надо ставить галки на отдельных строках. Чтобы было удобно надо завести кнопку, которая расставляет и снимает галки по всей «ветви дерева» вниз. Но я пока не знаю потребуется это или нет потому заготовка позволяющая быстро довести до рабочего состояния у меня уже есть а полной работоспособности нет. Вот когда у меня тут действительно станет много-много-много строк будет понятно нужен именно такой механизм или нет. Пока есть только предположение. Точный ответ как обычно дадут вводимые данные и способ, которым их удобно вводить.
В начале текста я написала, что программа – электронное описание реальности. Эта реальность, заливаясь в программу и должна постепенно менять структуру программы под свою «фигуру». Я могу только предположить как это будет но точно я не знаю.
Следующее из разряда самоочевидного. Если есть информация неплохо бы знать, откуда она взялась. Т.е должно быть точно зафиксировано, кто состав препарата возник из описания этого самого препарата. С препаратами всё понятно. А вот с какой страницы учебника взялось то, что какой-то эндокринный орган производит такой-то гормон найти иногда сложно. Потому у связей объектов появились источники информации в виде исходных текстов.
Первая проблема:  просто длинный текст читать неудобно. Его хоть на абзацы разбивать надо. Логично хранить информацию в виде HTML:

… который легко делает информацию читаемой и сразу видной:

Тэги <b> и <p> можно распрекрасно вставить руками, но тоже сразу вопрос: сколько времени это потребует? Первое же столкновение с реальной информацией показывает, что это тоже надо автоматизировать. Появляется инструмент («обработка»), ускоряющий форматирование текста:

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

Вещества ядра уже перекинуты в ключевые слова:

Для каких-то слов уже нашлось точное соответствие в справочнике объектов. Что-то прямо отсюда можно туда добавить. Но ведь если в справочнике уже введён «Пшеничный крахмал» то «Крахмала пшеничного» в нем не надо. Можно войти в справочник и поискать там по подстроке. Это требует секунд. Но секунды тоже время. И это много времени если искать надо постоянно. Потому проще сделать быстрый поиск прямо на этой форме. Вот он:

Пшеничного крахмала не нашлось. Но именно крахмалы побудили сделать такой поиск вместе с отличием в химических названиях. В описаниях препарата принято писать «магния стеарат», а общепринятая видимо химическая практика даёт – «стеарат магния»:
Стеарат магния
Может крахмаля и недостаточный повод, но уже обнаруженное хотя бы одно рассогласование правил в названиях означает, что искать похожие в этой медицинской реальности придётся очень часто.
Виды характеристик объектов тоже стали быстро разрастаться. Этот справочник тоже явно будет длинным. Для сумамеда добавлена такая информация:

А всего строк уже столько:

Разрастание справочника явно требовало добавить группу – объект, позволяющую выбирать характеристики только объектов конкретного типа.
Это позволило, например сделать так при добавлении цитаты с информацией:

Я хочу добавить характеристику. Но добавить новый текст я могу только в «Фарамкологические свойства». По слову «Сумамед» было найдено то, что это «Препарат». А всё остальное для него уже введено потому эти строки убраны из того, что можно добавить. Это всё те же секунды времени и чуть меньшие требования к вниманию (неправильно невозможно выбрать).
Это пока только ввод информации. Только одной (длинные строки). И это самое начало ввода, т.е ввод только описаний препаратов.
Здесь пока вообще нет поиска. Во-первых чтобы экспериментировать с поиском или, тем более с анализом найденной информации надо хоть что-то ввести для этого самого анализа. Во-вторых справочники скорее всего будут иметь жёсткую логическую структуру пока неизвестно какую. Чтобы это понять надо ввести разнотипную информацию а не несколько описаний препаратов.  Чтобы понять как (и вообще понять достаточно ли этой структуры) данные надо просто ввести причём. Причём их должно быть довольно много введено. Только после этого имеет смысл думать о каком-то поиске. Иначе его просто пробовать не на чем будет (нет информации).
Плюс такая штука без данных, т.е возможности хоть кого-то использования вообще непонятно зачем нужна. Это же электронный справочник. Зачем нужен пустой справочник? Если 1С-овские примеры нужны, то три готовых конфигурации тут лежат:
http://akostina76.ucoz.ru/publ/5-1-0-8

Так что это все не завтра…