VD>CREATE TABLE Z
VD>(
VD> idZ int NOT NULL PRIMARY KEY,
VD> ZName varchar(100) NOT NULL
VD>)
VD>
VD> Вторая таблица – это таблица содержащая проводки: VD>
VD>CREATE TABLE Oper
VD>(
VD> idOper int IDENTITY (0, 1) NOT NULL PRIMARY KEY,
VD> Db int NOT NULL FOREIGN KEY REFERENCES Z,
VD> Cr int NOT NULL FOREIGN KEY REFERENCES Z,
VD> OperDate datetime NOT NULL,
VD> OperSum float NOT NULL
VD>)
VD>
VD>А вот описание этих таблиц в виде ER-диаграммы: VD>
По поводу реляционности таблицы Oper: атрибуты Db и Cr зависят друг от друга хотя бы потому,
что не все их сочетания допустимы.
Здравствуйте retalik, Вы писали:
R>Проясните, пожалуйста,
А что мы на ВЫ?
R>... вот что. Для количественного учета все понятно (ящик варенья, бочка печенья...). Остатки на складе получаются обороткой за период.
R>А если необходимо учитывать единицы товара, скажем, холодильники, этот метод применим?
Для учета, разницы межу банкой варенья, килограммом сахара и автомобилем нет никакой. Скорее всего речь идет о учете товара в разных единицах измерения и/или о учете комплектов.
Первая задача решается введением в справочных номенклатур списка единиц измерений и полей содержащих информацию о количестве минимальных единиц в данной. Таким образом учет всегда ведется в минимальной единице с указанием типа хранения по которому можно рассчитать количество товара в необходимой единице (например, песок всегда учитывается в килограммах, но можно указать единицу хранения "пачка" и рассчитать количество пачек).
Вторая решается специальной организацией номенклатурного справочника. При этом всегда учитываются комплекты, но специальным пересчетом можно получить остатки и по отдельным составляющим. Принцип здесь такой же как и в случае обычного атрибута, только применимо не к z-объектам, а к номенклатуре.
R>Как — детализацией типа "одна позиция — одна накладная"? Или я чего-то не понимаю?
Одна проводка равна одной накладной. При этом в накладной может учитываться любое количество номенклатур товара, но одна номенклатура может фигурировать только один раз для накладной.
R>Требования:
R>Уникальная итендификация каждого товара (например, выводить его инвентарный номер в накладных).
Это атрибут товара. Он зависит только от организации номенклатурного справочника. В накладной хранится только идентификатор товара... остальное узнается через джоины к таблицам товаров.
R>Целостность данных (нельзя продать дважды один и тот же товар, нельзя продать единицу товара до того, как она получена и т.д).
Это бизнес логика. К организации данных она имеет очень отдаленное отношение.
R>Получение развернутых отчетов о продажах, складе, приходе и т.д.
Про это я уже говори... нужно только интерполировать рассуждения о z-объектах, но номенклатуру.
R>Если это решается только полной детализацией проводок, то возникает еще один вопрос: насколько это накладно для современных БД, ведь объем данных возрастает многократно?
Почему? Количественно-суммовой учет ведется как детализация обычного суммового. Как я уже говорил одна проводка может содержать множество детализирующих записей. Количественный учет ведется только там где это необходимо, все таблицы нормализованы, таким образом количество записей близко к идеальному. Несомненно при больших объемах записей будет много и придется решать проблему производительности. Для этого можно воспользоваться индексированными/материализованными view из SQLServer 2000/Oracle, или создать их подобие на триггерах/среднем слое.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте frogge, Вы писали:
F>По поводу реляционности таблицы Oper: атрибуты Db и Cr зависят друг от друга хотя бы потому, F>что не все их сочетания допустимы.
Это уже бизнес логика. Реляционной модели она не противоречит. То о чем ты говоришь может быть выражено в виде констрэйнов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте alexm1202, Вы писали:
A>Здравствуйте VladD2, Вы писали:
A>>>Я бы хотел принять участие в подобном проекте. Но не как представитель фирмы, на которой я работаю (у нас здесь в данный момент задачи не учетные — транспортные), а как энтузиаст-одиночка Ну и со всеми вытекающими.
VD>>Ну, что-же. Остается выяснить как можно кооперироваться и какими возможностями (знаниями) ты обладаешь.
A>Как кооперироваться. Имхо, обсуждаем построение системы, режем ее на части, договариваемся об интерфейсах, реализуем, тестируем, реализуем, тестируем, тестируем... По поводу возможностей — ну, могу CV прислать.
Нужно пробывать...
Можно просто по аське пообщатся (#22065541, лучше поближе к вечеру).
Аськи у меня нет, да и времети в онлайн вести разговоры тоже. Так что лучше в конфе. Тем более это может привлечь других людей.
A>>>А ты не думал о том, чтобы сделать ядро свободным?
VD>>Вот даже сейчас думаю. Есть только одна загвоздка я не верю в то, что полностью открытый проект может дать возможность зарабатывать деньги. А деньги зарабатывать нужно. Хотя бы для того чтобы кормить программистов. Они сейчас не дешивы. Хотя будь моя воля только и занимался бы созданием ПО, причем бесплатно.
A>Ну, я возможно неточно выразился, я не предлагаю весь проект делать свободным, и не все компоненты, которые на твоей диаграмме на http://www.optim.ru/Software/rus/ascConcept/ascconcept.asp помечены как ядерные и низкоуровневые. К примеру, свободный визуальный конструктор — это, имхо, перебор. Но библиотека доступа к данным и еще какие-то низкоуровневые компоненты, как мне кажется, вполне могут быть открытыми, это только на пользу проекту будет.
Надо обсуждать все более детально. Низкоуровневые компоненты мы как раз сделали. Правда, именно на COM. Сейчас речь идет о самом проекте.
VD>>С другой стороны ближайшие два года на неньги можно даже и не рассчитывать.
A>Вот, я тоже об этом же. Как мне кажется, стоит попытаться начать проект на свободной основе и посмотреть что из этого будет получаться.
Черт его знает. Можно начать свободное обсуждение, а там видно будет...
VD>>В закрытом виде сотридничество с отдельными программистами я себе вижу или как работу по контракту (задача против денег),
A>А такая схема реальна в данный момент?
Мы ее не пробывали, но ничего невозможного нет.
VD>>или если программист берет на себя большой кусок работы и получает (в будущем) долю от прибыли соотвествующую этому куску.
A>Тут все зависит от того, насколько большим будет этот кусок.
Эстественно.
VD>>Если проект станет открытым, то сотридничество может идти только в рамках доброй воли, а на счет денег (как я уже говорил) я даже и заикаться не буду. Тут темный лес.
A>Если честно, я просто не вижу сейчас альтернативы. Может, я ошибаюсь.
VD>>>>Обсуждение нужно и в стратегическом плане. Те технологии на которые мы делали ставки 5 лет тому назад потихоньку уступают место новым, но вот стоит ли прыгать? Короче, вопросов намного больше чем ответов. Думаю со всего этого нужно и начать.
A>>>Мое личное имхо — прыгать стоит. По параллельным сообщениям я понял что ты в сомнениях на этот счет?
VD>>Да? Ну, тогда я сейчас открою новую ветку http://www.rsdn.ru/forum/message.asp?mid=32159&only
VD>>и выскажу в ней свои мысли (за и против) по этому вопросу.
A>Ну, по этому поводу я согласен с отвечающим тебе IT, в том смысле что COM сделал свое дело.
Проблема в том, что нижний уровень уже сделан на COM.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте VladD2, Вы писали:
R>>Проясните, пожалуйста, VD>А что мы на ВЫ?
Для солидности :)) Вдруг еще кто-то ответить решит?
R>>А если необходимо учитывать единицы товара, скажем, холодильники, этот метод применим?
VD>Для учета, разницы межу банкой варенья, килограммом сахара и автомобилем нет никакой. Скорее всего речь идет о учете товара в разных единицах измерения и/или о учете комплектов.
Да, но один килограмм сахара от другого неотличим, а с автомобилями немного не так.
(skip)
R>>Как — детализацией типа "одна позиция — одна накладная"? Или я чего-то не понимаю? VD>Одна проводка равна одной накладной. При этом в накладной может учитываться любое количество номенклатур товара, но одна номенклатура может фигурировать только один раз для накладной. R>>Требования: R>>Уникальная итендификация каждого товара (например, выводить его инвентарный номер в накладных). VD>Это атрибут товара. Он зависит только от организации номенклатурного справочника. В накладной хранится только идентификатор товара... остальное узнается через джоины к таблицам товаров.
Основную идею понял, спасибо.
R>>Целостность данных (нельзя продать дважды один и тот же товар, нельзя продать единицу товара до того, как она получена и т.д). VD>Это бизнес логика. К организации данных она имеет очень отдаленное отношение.
Ну целостность-то имеет отношение к организации данных? Если можно что-то сказать на уровне констрэйнтов, зачем перекладывать это на триггеры?
Я имел в виду, что, пока на складе есть хоть один килограмм сахара, его можно продавать. А если на складе 5 автомобилей "Жигули", каждый из них продается отдельно (и единственный раз).
Ну да ладно, стало яснее.
Кстати, ты статью на базе этого обсуждения сделать не собираешься? Было бы неплохо...
VD>Почему? Количественно-суммовой учет ведется как детализация обычного суммового. Как я уже говорил одна проводка может содержать множество детализирующих записей. Количественный учет ведется только там где это необходимо, все таблицы нормализованы, таким образом количество записей близко к идеальному. Несомненно при больших объемах записей будет много и придется решать проблему производительности. Для этого можно воспользоваться индексированными/материализованными view из SQLServer 2000/Oracle, или создать их подобие на триггерах/среднем слое.
Кстати, давно хотел спросить: вы с каким Oracle работаете (если работаете)?
Браво! Снимаю шляпу. Такого полного ответа я не ожидал. Надо все это еще пару раз прочесть, чтоб проникнуться.
VD>Все проблемы с формированием базы и запросов разрешимы. Я больше задумываюсь над тем, что к универсальной структуре базы нужны универсальные механизмы работы. В далеком 96-м мы решили создать набор компонентов который стал бы оберткой над этой универсальной структурой и смог бы быть дополнительным уровнем абстракции. Первую попытку мы сделали в 97-ом...
А были ли реальные внедрения приложений на базе этого ядра? Или это пока чисто научный эксперимент?
VD>Так вот, ... к чему я виду? Не хочет ли кто присоединится к этому проекту.
Неплохая идея.
P.S. Прошу прощения за "оперативность". Был дико загружен.
P.P.S. Огромное спасибо за то, что не пожалел времени и своих идей, думаю многие почерпнут из них много полезного.
__________________________________
Василий Черневич (aka Willi)
Здравствуйте retalik, Вы писали:
R>Да, но один килограмм сахара от другого неотличим, а с автомобилями немного не так.
Это называется инвентарный учет. Когда учитывается не номенклатура, а экземпляр. В принципе реализуется введением зависимости "номенклатура равна экземпляру" для некоторого раздела справочника. Но обычно не нужно хранить информацию о экземпляре. Достаточно хранить дополнительные атрибуты типа номер машины. Правда при этом приходится копировать такие атрибуты для каждой записи где проходит такая машина. Агрегацию и другую групповую обработку при этом можно делать в виде иерархически организованного справочника групп.
R>>>Целостность данных (нельзя продать дважды один и тот же товар, нельзя продать единицу товара до того, как она получена и т.д). VD>>Это бизнес логика. К организации данных она имеет очень отдаленное отношение.
R>Ну целостность-то имеет отношение к организации данных? Если можно что-то сказать на уровне констрэйнтов, зачем перекладывать это на триггеры?
Ну, например, когда такие констрэйны должны завесить от данных в таблице и их нельзя выразить декларативными средствами. А так, конечно, чем проще решение тем оно жизнеспособнее.
R>Я имел в виду, что, пока на складе есть хоть один килограмм сахара, его можно продавать. А если на складе 5 автомобилей "Жигули", каждый из них продается отдельно (и единственный раз).
Так это и есть бизнес-логика. Тебе важно хранить путь каждого автомобиля..., а я их партией по 10000 штук толкаю. Так что системы учета декларативно у нас будут одинаковые, а бизнес-логика разная...
R>Кстати, ты статью на базе этого обсуждения сделать не собираешься? Было бы неплохо...
Черт его знает? Моет для Клиент-Сервера? У нас для него материала не хватает сейчас...
R>Кстати, давно хотел спросить: вы с каким Oracle работаете (если работаете)?
Скорее работали. С 8.1.5. Глючила эта версия страшно, но новую доставать было не до сук.
Сейчас вот достал 9i, но еще не ставил даже... времени нет на испытания.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте Willi, Вы писали:
W>А были ли реальные внедрения приложений на базе этого ядра? Или это пока чисто научный эксперимент?
На базе совсем дремучего (вроде до сих пор) работает руское представительство MAS Electrinics handls (или как там их), а на четь более свежем вот уже 6 лет пашит мая бухгалтерия.
VD>>Так вот, ... к чему я виду? Не хочет ли кто присоединится к этому проекту.
W>Неплохая идея.
W>P.S. Прошу прощения за "оперативность". Был дико загружен.
Да я сам загружен по самые помидоры. W>P.P.S. Огромное спасибо за то, что не пожалел времени и своих идей, думаю многие почерпнут из них много полезного.
Может из этго получится нечто что станет более востребованное...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Проектирование учетных систем ][
От:
Аноним
Дата:
22.03.02 19:20
Оценка:
Дорый день.
Забавно, мы на работе тоже конструктор написали. Сейчас его вторую версию писать начинаем. Родился он тоже попричине кривизны 1С, а так же малого бюджета проекта (вот такой парадокс, нужно было резко повышать КПД работы программистов). Если есть желания, напиши на mikkri@mail.ru, а то в форуме я случайный посетитель...
Ну и со всеми вытекающими. 
