Сергей Перовский
дата публикации 23-05-2011 14:27
Все современные крупные состояния нажиты преступным путем.
Все крупные современные системы управления предприятиями не поддаются модификации и сопровождению. Технические специалисты, занятые их внедрением, в частных разговорах описывают свои проблемы исключительно ненормативной лексикой. При слиянии двух фирм, даже в случае, если они пользовались одной и той же ERP системой, объединение их данных выливается, по сути, в повторное внедрение со всеми сопутствующими проблемами и расходами.
Разработчики утверждают, что причина в величине и сложности описываемого объекта.
Но тут есть и другие причины. В несоответствии идеологии, технологии и инструментария сложности задачи.
Что касается, конкретно, ERP систем, то они создавались путем формального объединения множества отдельных учетных, отчетных и управленческих программ, каждая из которых привносила в систему свои структуры данных.
Логично было бы сначала создать единую математическую модель для всего круга решаемых задач, а затем разработать структуру данных и реализовать на ней все необходимые алгоритмы. Но это требует разработки "с нуля" и современный менеджер с негодованием отбросит подобную идею, ведь по отдельности задачи уже решены.
Все уже привыкли к базам данных, содержащим сотни, а то и тысячи таблиц. Разработчики даже гордятся таким количеством, как начинающие программисты гордятся количеством строк кода. Положение очень напоминает то, что было перед появлением идеологии структурного программирования, когда, казалось, достигнут предел сложности программ. Человек не в состоянии понять чужой код, а, по прошествии некоторого времени, и свой собственный. Как и в случае со структурным программированием, решение лежит не в появлении новых методов, приемов и инструментов, а в отказе от некоторых методов и приемов, которые ведут к необоснованному росту сложности.
— Наша модель адекватна моделируемой системе(предприятию, электросети, сердцу и т.п.)— А каковы критерии адекватности?— Она правильно отображает основные свойства системы.— А какие свойства основные?— Ну, естественно .....— Почему именно эти?— Потому, что они нам нужны для решения наших задач!— Значит, модель адекватна системе не вообще,а относительно определенного набора задач!Часто повторяющийся диалог
Не бывает моделей правильных и неправильных. Бывают модели, которые позволяют или не позволяют решить определенные задачи с достаточной точностью.
К чему это отступление? К тому, что круг решаемых задач должен быть задан до разработки математической модели. Тем более, до проектирования структуры базы данных. Но это далеко не всегда возможно.
Мы создаем систему на многие годы и не знаем, какие задачи будут появляться. Что с этим делать? Строить как можно более универсальную структуру, заранее смирившись с тем, что она не будет оптимальна ни для одной конкретной задачи.
Сколько нужно программистов, чтобы ввернуть лампочку?
В качестве провокации, убедимся, что любой набор объектов можно сохранить в ОДНОЙ таблице.
Вот такой заголовок:
<Имя объекта, Имя атрибута, Значение атрибута, Тип атрибута>
Предвижу ехидный вопрос о типе поля "Значение атрибута". Отвечаю: это очень широкий столбец :)
Для простоты примем, что это BLOB-поле.
Разумеется, это нисколько не лучше, чем тысяча таблиц. Но я к такому экстремизму и не призываю. Просто, убедившись в достижимости такого "идеала", можем более взвешено выбирать структуру.
Будем постепенно увеличивать количество таблиц, сглаживая главные недостатки минималистского подхода, но стараясь не перейти границу обозримости структуры.
Первый, явный, недостаток — медленная работа с текстовыми и, особенно, BLOB полями. Перейдем к кодам.
<Код объекта, Код атрибута, Код значения атрибута, Код типа атрибута>
С такой таблицей работать много веселее. Можно построить очень эффективные индексы. Всевозможные вычислительные алгоритмы, где обращения к базе попадаются внутри многократно вложенных циклов, ускоряются принципиально. Правда, отчеты на прямую не построить, придется еще завести словарь: <Код, Текст>. Отступив на шаг, мы заметно выиграли.
Следующий шаг связан с типами объектов, все-таки хранить в одной таблице все объекты, это лишать себя многих возможностей СУБД.
Но и бездумно плодить таблицы на каждый чих мы тоже не будем. Будем искать компромисс.
Количество базовых типов объектов должно быть обозримо. Психологи утверждают, что человек может одновременно оперировать 7-9 сущностями. Для гарантии примем 7. Такое количество базовых типов мы можем себе позволить.
Чтобы и тут раскрепостить мышление, убедимся, что, теоретически, можно обойтись ОДНИМ типом объекта. TStringList позволяет хранить любое количество именованных атрибутов :)
Пусть есть некоторая иерархия объектов:
Type
TC1 = class
A1: integer;
A2: integer;
end;
TC2 = class(TC1)
B1: integer;
end;
TC3 = class(TC1)
B2: string;
end;
|
|
Для хранения всех объектов, наследников C1 потребуется такая пара таблиц:
<Код объекта, A1, A2> <Код объекта, Код значения атрибута, Код типа атрибута>
Первая позволяет работать с теми атрибутами, которые есть у всех, как с уникальными полями таблицы. А все расширения попадают в общий список во второй таблице. Однако поиск по дополнительным атрибутам не вызывает трудностей.
Для 7-ми иерархий объектов потребуется 14 таблиц. Делать ли словарь общий или также сделать их 7 штук? Это чаще зависит от особенностей используемой СУБД, чем от особенностей задачи. Но в нескольких словарях может начаться дублирование текстов. Поэтому, как правило, делаю общий.
Итого 15 таблиц для отображение любой системы.
Это тоже, своего рода, идеал. Реально получается больше. Иногда вдвое больше. Но это уже обозримая система с известной структурой.
Кругом гуляли подозрительные типы. Целая улица типов.
Эдуард Успенский "Колобок идет по следу"
Код типа атрибута — подозрительное поле :)
Для чего оно и как работает.
Когда-то оно называлось "Единицы измерения". Но, постепенно, его функции расширились. По сути, это код процедуры, которая превращает код значения в реальное значение. Чаще всего, это поиск в словаре. Это может быть поиск в специальной таблице — вот откуда часто возникают дополнительные таблицы. Может быть преобразование типа — например, в ячейке "Код значения атрибута" может храниться вещественное число. Может быть и сложный пересчет по какой-нибудь логарифмической функции. Мне пока хватало 4-х миллиардов значений кода, чтобы с нужной точностью отобразить все возможные значения любого типа.
Примечание: От автора материал получен со следующим комментарием: "Поскольку текст написан достаточно провокационно, это скорее не статья, а затравка для дискуссии на базарной площади". Размещение материала в разделе "Свитки" — инициатива администрации. Показалось, что здесь дискуссия может развиваться ничуть не хуже ;)
 Обсуждение материала [ 02-09-2011 08:54 ] 108 сообщений | 
