Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
 Технология открытой разработки (to Zaxx)  [new]
dkstranger
Member

Откуда: Москва
Сообщений: 341
Я тут веду бесконечный разговор с Zaxx-ом
по поводу открытой разработки.
Предлагаю новую тему - беру на примере биллинг-а
(сильно упрощенно)

Итак, часть первая - постановка задачи
(повторяю, упрощено - для реальных систем
гораздо сложнее :))

Бизнесс - процессы
1. Выставление (утверждение) счетов покупателям
2. Приход оплаты от покупателя
3. "Разноска" - соотнесение 2 с 1
4. Отгрузка (оказание услуг покупателю)

Бизнесс - объекты
1. Задолженность покупателя по оплате
2. Обязательства наши по отгрузке (оказанию услуг)
3. Неразнесеннные суммы (авансы)
4. Продажи
5. Стоимость товара (себестоимость услуги)
6. Сумма пришедших от покупателе денег

По принципу двойной записи на одну сумму!!!
БП 1 увеличивает БО 1 и 2 на одну сумму !!
БП 2 увеличивает БО 3 и 6
БП 3 уменьшает БО 1 и 3
БП 4 - две транзакции
а) по сумме продаж
увеличение 4 и уменьшение 2
б) по себестоимости (если есть)
снижение 4 и уменьшение 5

Продолжать :)?
20 сен 02, 18:39    [56523]     Ответить | Цитировать Сообщить модератору
 Re: Технология открытой разработки (to Zaxx)  [new]
Zaxx
Guest
Продолжай.
Чего тут есть по поводу открытой разработки ? И что тогда закрытая?
20 сен 02, 19:28    [56540]     Ответить | Цитировать Сообщить модератору
 Re: Технология открытой разработки (to Zaxx)  [new]
Zaxx
Guest
2 dkstranger
Ну формализовали вы систему, ну процессы, объекты выделили и что? Все через это проходят. Не открыли вы америку, и велосипед не изобрели. Все именно так и работают.

Собственно если ваше понимание открытости не влияет на выбор СУБД, то это тред можем закрыть и флеймить будем в двух оставшихся. Считаем что по этому вопросу у нас единодушие.
20 сен 02, 20:56    [56553]     Ответить | Цитировать Сообщить модератору
 Re: Технология открытой разработки (to Zaxx)  [new]
dkstranger
Member

Откуда: Москва
Сообщений: 341
Иду дальше.
/открытость будет через 2 шага :)/
Еще немного по биллингу /извини,
но это довольно важно для дальнейшего разговора/.

Как любая учетная система, биллинг по идее,
должен покоится на 3 китах
1. Принцип непрерывности - думаю, ясен, но
на пальцах - можно работать с любым периодом,
рассматривая только данные этого периода и
входящие остатки - на практике это означает
невозможность правок "назад" /отдельно можно
обговорить, что же делать, если исправление необходимо/
2. Принцип целостности - итоговый показатель
всегд равен сумме составляющих - т.е. можно определить
минимальную "атомарную" аналитику - и любой
показатель получать группровкой
3. Принцип двойной записи /баланс/ - грубо говоря,
ничего никуда не исчезает и ниоткуда не появляется
/пример был дан в предыдущей мессаге :)/
23 сен 02, 10:21    [56800]     Ответить | Цитировать Сообщить модератору
 Re: Технология открытой разработки (to Zaxx)  [new]
dkstranger
Member

Откуда: Москва
Сообщений: 341
Теперь - последний предварительный шаг :)

Немного остановлюсь на цели и приоритете
серьезной информационной системы (в частности,
биллинг).

Особо хочется подчеркнуть, что заказчиком и основным
потребителем серьезной системы является НИ ОПЕРАТОР,
КОТОРЫЙ С НЕЙ РАБОТАЕТ, НИ МЕНЕДЖЕР
СООТВЕТСВУЮЩЕГО ПОДРАЗДЕЛЕНИЕ, а РЕАЛЬНЫЙ
РУКОВОДИТЕЛЬ, ПРИНИМАЮЩИЙ РЕШЕНИЯ В
МАСШТАБЕ КОРПОРАЦИИ и ИСПЫТЫВАЮЩИЙ
НЕОБХОДИМОСТЬ в адекватной оперативной
информации.

Таким образом, в качестве приоритетов не может быть
ни производительность системы, ни удобство работы,
ни пожелания заказчика - ОСНОВНЫМ ПРИОРИТЕТОМ
должно быть ТЕХНОЛОГИЧЕСКОЕ ОБЕСПЕЧЕНИЕ
АДЕКВАТНОСТИ вводимой информации (принципы см
предыдущ. мессагу)
23 сен 02, 10:28    [56801]     Ответить | Цитировать Сообщить модератору
 Re: Технология открытой разработки (to Zaxx)  [new]
dkstranger
Member

Откуда: Москва
Сообщений: 341
Ну, и потихонечку переползаем к открытости :).

Начнем с первого краеугольного камня

РАЗДЕЛЕНИЕ ДАННЫХ, ИНТЕРФЕЙСА РАБОТЫ И
ОТЧЕТНОСТИ (эксплорера).

Поскольку основным является технологическая
поддержка данных предметной области (ни в коем
случае не требований заказчика !) разработка
информационной системы (в частности, биллинг-а)
должна осуществляться НЕЗАВИСИМО по трем
направлениям
1. Разработка структуры данных, поддерживающей
предметную область - должна обеспечивать
возможность развития и модификации без изменения
структуры данных ( об этом, в след раз)
2. Разработка интерфейсов - поскольку окончательная
детальная постановка задачи (например, IDEFX) -
утопия, допустимо (а часто и необходимо) на старте
разработки создание клиентов "заглушек",
обеспечивающих ввод данных (крайне желательно
иметь на старте разные клиенты для разных рабочих
мест). Принципы открытой разработки интерфейсов и
клиентов - после принципов открытой разработки
структуры данных (т.е. через раз:))
Крайне нежелательно ради "улучшения интерфейса"
изменять структуру данных (добавлять поля в
существующие таблицы) - при необходимостии
для этих задач лучше организовывать параллельную
структуру (если нужно, можно это обговорить отдельно)
3. Что касается отчетности.
Речь о ней может идти ТОЛЬКО ПОСЛЕ ЗАПУСКА
системы в пилотном режиме и НАБОРЕ РЕАЛЬНЫХ
(или, по крайней мере, тестовых) данных.
Крайне важно, чтобы отчетность не задевала
основную структуру данных (если что-то нужно,
добавляетс отдельная структура :))

Общий подход - САМОЕ ОСНОВНОЕ - структура
данных, она создается на основе ТОЛЬКО предметной
области и не должна путаться ни с интерфейсами
работы ни с отчетностью!!!

Этот подход обеспечивает независимую разработку -
предметной области (см пример - первую мессагу),
рабочих мест (что является важной, но ни в коем
случае ни основной задачей) и отчетности -
здесь отдельная очень большая тема, но об этом в самом
конце ...
23 сен 02, 10:42    [56806]     Ответить | Цитировать Сообщить модератору
 Re: Технология открытой разработки (to Zaxx)  [new]
dkstranger
Member

Откуда: Москва
Сообщений: 341
Теперь немного о структуре данных
(опять таки на примере биллинга).

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

1. Сначала немного о так называемой первой
нормализованной форме.
Думаю, не надо здесь давать ее определение
/это - всем известная азбука реляционных БД/.
Остановлюсь только на нескольких наиболее
распространенной ошибке
- сумма счета определяется как сумма составляющих
(см принцип целостности), поэтому в таблице Bills
(счета) НЕ МОЖЕТ БЫТЬ ИТОГОВОЙ СУММЫ СЧЕТА -
она должна определяться как соответсвующая
группировка таблицы BillItems (пункты счета).
Понятно, что этот принцип относится ко всем данным -
после 2-3 лет работы /а тем более после 5 лет с
Oracl-ом :)/ у разработчика не возникает проблем
нормализовать практически любую структуру данных,
исключив избыточность /на самом деле иногда
избыточность допустима, но об этом сильно потом :)/
2. Теперь немного остановимся на информации о
покупателе.
Допустим, мы хотим знать его ИНН, адрес и т.п.
Лобовой путь - определить в таблице Customers
/покупатель/ соответствующие поля.
Это - пример "закрытого" подхода.
Чуть более грамотно определить две таблицы
create table PropStrType( -- стр свойства покуп
id integer Primary key,
caption varchar(75) )

create table Customers_StrInfo(
id integer Primary key,
parent integer references Customers,
child integer reverences PropStrType,
valuestr varchar(75)
UNIQUE (parent,child)
)

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

Но на самом деле более открыты яляется дальнейшее
развитие этого подхода /в след мессаге :)/
23 сен 02, 11:12    [56816]     Ответить | Цитировать Сообщить модератору
 Re: Технология открытой разработки (to Zaxx)  [new]
dkstranger
Member

Откуда: Москва
Сообщений: 341
В продолжении предыдущего примера...

Я не случайно назвал поля безличными
именами parent и child (многие назвали их
по аббревиатуре, что-то типа IdCust и IdStrProp).

Дело в том, для реализации предметной области
необходимо определить множество однотипных объектов.
Так, например, все списки обектов могут иметь
структуру
Id integer Primary key,
Caption varchar(75), -- коментарий
SrtOrd int, -- порядок вывода в списке по умолчанию
Viisible int default 0 -- <>0 для "устаревших" записей

Списки свойств и их значений струткру, описанную
в пред мессаге.

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

Это уже почти объектная реализация на реляционной
БД :) ...

Думаю, про объектный подход достаточно
/если интересно, могу продолжить/.

Сейчас остановлюсь на след принципе
ФИЗИЧЕСКОЕ РАЗДЕЛЕНИЕ ДАННЫХ (след мессага :))
23 сен 02, 11:23    [56822]     Ответить | Цитировать Сообщить модератору
 Re: Технология открытой разработки (to Zaxx)  [new]
dkstranger
Member

Откуда: Москва
Сообщений: 341
ФИЗИЧЕСКОЕ РАЗДЕЛЕНИЕ ДАННЫХ -
очень важное (и весьма непревычное) требование
открытости разработки...

Попробую показать это на примере :)

Для простоты разделю все данные на след группы

а) базовые справочники
- настройки
- базовая информация (данные о покупателях и т.п.)
1. оперативные данные /например, текущий месяц и
вперед/
2. текущие данные /например, тек год/
3. прошлые данные - например, данные прошлых лет,
недоступные для модификации ..

Целесообразно данные 1, 2, 3 /или хотя бы 1+2 и 3/
разнести по разным таблицам.
При условии работы с данными не напрямую, а через
соответ интерфейсы,
основные плюсы в таколм подходе след
- возможность иметь разные структуры для текущих
и старых данных
Это - основной плюс, позволяющий при сохранении
общих интерфейсов, гибко подстраиваться под
изменения бизнеса - ценовая политика, налоги,
законодательства и т.п. часто имеют смысл только
в течении одного периода, в нем они и обрабатываются.
Физическое разделение позволяет при общем анализе
не думать об особенностях каждого периода,
а в каждом периоде учитывать всю его специфику.
Резко упрощается обработка данных.
- Можно обеспечить гарантию неизменяемости
"старых" данных /просто запретом на модификацию
соответствующих таблиц/

По принципу непрерывности работа с текущими данными
может идти независимо, опираясь на соответствующие
остатки...

Дополнительным /но, на самом деле, совершенно не
важным !/ является резкое повышение
производительности - текущая работа идет не на полном
объеме данных, а только на подмножестве актуальных
данных...

К тому же резко повышаются возможности развития и
модификации - все новые изменения можно опробывать
на копии, не боясь повредить старые или текущие
данные...

Думаю сделать маленький перерыв - через 2 часа
уезжаю в командировку. Если есть интерес,
можно продолжить - тема необъятная, а накопилось
до фига материала :)
23 сен 02, 11:44    [56830]     Ответить | Цитировать Сообщить модератору
 Re: Технология открытой разработки (to Zaxx)  [new]
Zaxx
Guest
2 dkstranger

По поводу справочников у меня сложилась похожая картина, но все справочники лежат в одной структуре (4 таблички: Вид справочника , вид атрибута справочника, справочник, атрибут спавочника.)

Снова повторюсь "если ваше понимание открытости не влияет на выбор СУБД, то это тред можем закрыть"...
23 сен 02, 14:15    [56933]     Ответить | Цитировать Сообщить модератору
 Re: Технология открытой разработки (to Zaxx)  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
2dkstranger

дайте ссылку на исходники, положите рядом текст GNU-шной лицензии и вопрос можно считать закрытым ;)
24 сен 02, 21:35    [57467]     Ответить | Цитировать Сообщить модератору
Все форумы / Сравнение СУБД Ответить