Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Укажите, пожалуйста, на ошибки в проектировании БД для небольшой [D7, WinXP]

Страницы: 1 2 3 >
miwa © (2004-11-17 00:01:00)
бухгалтерской программы.
Таблицы:
Товары: - ID; - ID предка (для работы с категориями товаров); - название. Работники: - ID; - имя; - пароль (для контроля со стороны программы, но не СУБД); - еще что-то. Торговые точки: - ID; - имя; - еще что-то. Поставщики: - ID; - имя; - еще что-то. Приход товара: - ID; - ID товара; - ID поставщика; - цена; - дата; - № накладной; - примечание. Продажа: - ID; - ID товара; - ID работника; - ID торговой точки; - текущая цена; - дата. Наличие товара: - ID товара; - ID торговой точки; - количество. Наценки: - ID товара; - наценка.
В программе не планируется учет налогов и прочих заумностей ;о)).
Заранее благодарен.

Vemer (2004-11-18 18:54:00) [1]
to Miwa

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

miwa (2004-11-18 17:38:00) [2]
> Sergey13 [35]
Вообще-то, я этого не предлагал; я просто сказал, что такого скорее всего не будет, но гарантировать не могу, так как... ну и далее по тексту.
Типа оправдываюсь. :o))

Vemer (2004-11-18 16:49:00) [3]
To MS_Guns:

У моего заказчика первичны операции, а при необходимости генериться документ (пример - 1 счет на 10-15 продаж). Это в бухгалтерии первичен документ :). Задачи разные.

Под "операцией" подразумеваеться какое-то действие.

С уважением.

miwa (2004-11-18 11:09:00) [4]
> Sergey13 [37]

Спасибо, буду иметь в виду и в случае осложнений вспоминать... ну, например "Ах, Sergey13, $@#%^$#%^#$^@# накаркал ;o))"
А если серьезно - спасибо, постараюсь учесть.

Sergey13 (2004-11-18 11:03:00) [5]
2[36] miwa © (18.11.04 10:53)
>А в уже упоминаемом мною "Мире Интербейз" неплохо описана ...
Там описана программная реализация. А проблемы могут возникнуть (я не утверждаю, что обязательно возникнут 8-) из-за усложнения бизнес-логики.

miwa (2004-11-18 10:53:00) [6]
> [29]

1, 2. Простите, а смысл? Что это дает?
3. Опаньки, а это идея. Надо будет подумать. Спасибо.
4. Тоесть смысл 1 и 2 только в этом? Вы простите, если я что-то не то спрашиваю. Как я уже писал - это моя первая серьезная работа с бухгалтерией, да и с базами - максимум третий проект, да и то первые два были несерьезные. Учусь я пока.

> [31]

А-а-а, тоесть ЭКК - Электронные Кассовые Коды? Хм. Опять же - не думал на эту тему, так как это даже не упоминалось.
А какие возможны решения кроме ручного ввода? Соединятся по какому-нибудь com-порту с кассой и вытягивать-записывать?
За скидки спасибо. В смысле, за напоминание о них - тоже выпустил из внимания.

> [33]

А в уже упоминаемом мною "Мире Интербейз" неплохо описана разработка ХП для работы с такими структурами - вот их я и использую за основу. Надеюсь, я все же не настолько тупой, чтобы хорошие рабочие примеры угробить ;o))

Sergey13 (2004-11-18 10:49:00) [7]
2[34] msguns © (18.11.04 10:45)
>Как это ? Что ж это за логика, которая позволяет так делать ?
Это началось с [11] miwa © (17.11.04 11:39)

msguns (2004-11-18 10:45:00) [8]
>Vemer © (18.11.04 00:10) [29]
>Прочитал не все, но вроде этого не было.
>1) Сделать единый журнал операции (покупки, продажи и т.д.)

Не нужен в принципе. По необходимости легко получается запросом

>2) Таблицы покупок и продаж товара следует также объединить в 1 журнал количество и себестоимость вычислять динамически (по возможности), строки прикреплять к операциям.

Глупости. Первичны всегда документы, а не операции. По крайней мере в складских задачах. Не каждому документу может соответствовать операция (счет, например) и не каждой операции - документ (оплата за товар наличными, к примеру). Это во-первых.
К тому же при учете по поставкам таблицу приходов надо выносить отдельно, т.к. ссылки на ее строки (коды поставок) будут присутствовать в фактурах других документов. Это во-вторых.
По каждой документо-строке делать операцию означает то, что получаем "неоткатные" операции, которые непонятно кому и зачем нужны. ИМХО, к операциям следует подходить по принципу "Одна операция - одна проводка". Это в-третьих.
По поводу "вычислять себестоимость динамически" (опустим безграмотность этой фразы с т.зр. бухучета) см. [15]

>3) Покупателей, поставщиков, поставщиков услуг (вода, свет и т.д.) - тоже в 1 таблицу контрагентов.

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

>4) Для вычисления например остатков товара по журналу товаров сделать примерно такую структуру:

Есть опять-таки 2 подхода к остаткам (и не только по товару, а по сальдо с партнерами, сальдо на р/с в банках и т.д.):
1. Наличие таблицы сальдовых помесячных остатков. Ускоряет расчеты, но приводит к несколько бОльшим затратам памяти (доп.таблицы в общем-то немаленьких размеров)+усложняет логику
расчетов. Предполагает наличие расчетного периода, вне которого блокируются корректировки (т.е. для правок "прошлого" необходим сторнирующий документ)
2. Расчет производится по необходимости по всему движению за весь период хранения информации. Во избежание "тормозов", начинающихся после N-го месяца эксплуатации приложения и БД, рекомендуется делать чистку БД с удалением всего движения (создается один рез.документ, вносимый в БД как нач.приход "ниоткуда" или же как акт инвентаризации) до какой-то пограничной даты.

>GanibalLector © (18.11.04 00:30) [31]
>Кстати,иногда необходимо работать со скидкой.А они бывают разные...на моей памяти 5 разных.

Не все ЭКА поддерживают.

>GanibalLector © (18.11.04 00:31) [32] Если статья,то не могли бы Вы сообщить адрес.И еще,БОЛЬШАЯ ПРОСЬБА...а можно ли взглянуть на Вашу структуру БД?

Нет, это не статья, а "из головы". А в голове появилось из личного опыта работы + обсуждений в разных форумах, в т.ч. этого.
Пользуясь случаем, хочу выразить горячую благодарность и форуму, и тем Мастерам (выделять никого не буду), которые участвовали в обсуждениях данной проблемы (и не только ее)

>Sergey13 © (18.11.04 09:58) [33]
>потому что возможно когда-то товар сделали группой

Как это ? Что ж это за логика, которая позволяет так делать ?

Sergey13 (2004-11-18 09:58:00) [9]
2[28] miwa © (17.11.04 23:27)
> Ну, как вариант - я могу не видеть проблемы из-за неопытности, но это не значит, что ее у меня нет. ;о))
Например самая первая возможная проблема. Выбрать товары определенной группы. В твоем случае придется рекурсивно проверять, а нет ли товара на родителе, потому что возможно когда-то товар сделали группой. Сам понимаешь во что это может вылиться.
Вообще динамическая структура (а при таком подходе фактически получается именно динамическая структураданных) та еще песня. Если пока нет опыта работы даже со статической, я бы не советовал такой подход.

GanibalLector (2004-11-18 00:31:00) [10]
2 msguns
Понравилось мне Ваше [15].Хотел поинтересоваться...это Ваше мнение или это статья какая-то???Если статья,то не могли бы Вы сообщить адрес.И еще,БОЛЬШАЯ ПРОСЬБА...а можно ли взглянуть на Вашу структуру БД?

GanibalLector (2004-11-18 00:30:00) [11]
> Или это не то?
Не то!Имеется в виду кассовый аппарат.
Кстати,иногда необходимо работать со скидкой.А они бывают разные...на моей памяти 5 разных.

Vemer (2004-11-18 00:11:00) [12]
Правильная версия последнего запроса:

Select Sum(OPER_TOV_Kolvo * TOV_STATE_TYPE) From Table1, Table2 Where TOV_STATE_NO = TOV_STATE_NO

Vemer (2004-11-18 00:10:00) [13]
Прочитал не все, но вроде этого не было.
1) Сделать единый журнал операции (покупки, продажи и т.д.)

2) Таблицы покупок и продаж товара следует также объединить в 1 журнал количество и себестоимость вычислять динамически (по возможности), строки прикреплять к операциям.

3) Покупателей, поставщиков, поставщиков услуг (вода, свет и т.д.) - тоже в 1 таблицу контрагентов.

4) Для вычисления например остатков товара по журналу товаров сделать примерно такую структуру:

Типы товаров операции
TOV_STATE_ID - ID; TOV_STATE_NAME - название TOV_STATE_TYPE - тип (-1 расходная, 0 - нейтральная(перемещение), 1 приходная);
Журнал товаров операции
OPER_TOV_ID - ID; TOV_STATE_NO - FK по TOV_STATE_ID; TOV_NO - FK по ID товара; OPER_TOV_Kolvo - количество; OPER_TOV_Cena - цена единицы;

Остаток товара получаем как
Select Sum(OPER_TOV_Kolvo * TOV_STATE_NO) From Table1, Table2 Where TOV_STATE_NO = TOV_STATE_NO

Пока все.

miwa (2004-11-17 23:27:00) [14]
Простите, как то выпустил из внимания два поста.

> [18] msguns © (17.11.04 12:26)
> считаться не может. Кстати, а как планируется загружать
> ЭККи ? Ручками ?

Знаете, я бы с большим удовольствием вам ответил, но должен признаться, что не знаю, кто такие ЭККи. Ручками будут вносится названия, категории товаров, цены, поставщики. Или это не то?

> [17] Sergey13 © (17.11.04 12:25)
> 2[16] miwa © (17.11.04 12:17)
> Ну если ты не видишь проблемы, то может ее и нет для тебя.
> 8-)

Ну, как вариант - я могу не видеть проблемы из-за неопытности, но это не значит, что ее у меня нет. ;о))

miwa (2004-11-17 16:12:00) [15]
>[26] Sergey13

А кроме всего прочего эта фирма - это еще и два компютерные клубы. Соответственно на огненном пингвине - раздача и учет интернета. Еще там выделенные сервера для каких-то игрушек крутятся, насколько мне известно. Возможно, еще что-то.

Sergey13 (2004-11-17 14:54:00) [16]
2[24] miwa © (17.11.04 14:37)
И чего у них на этом летающем огненном пингвине крутится? Просто интересно. Если
>фирма-заказчик - это 10 человек если считать шефа и уборщиц;

msguns (2004-11-17 14:50:00) [17]
1С работает с MS SQL

miwa (2004-11-17 14:37:00) [18]
> [22]

Ну, этот вопросс, конечно, не совсем ко мне, но все же. Во-первых оно будет весьма похоже на "из пушки по воробьям", ну а во-вторых - сейчас используется linux-сервер с firebird на борту. Это тоже, ИМХО, накладывает некоторые ограничения, нет?

msguns (2004-11-17 14:37:00) [19]
>KSergey © (17.11.04 14:09) [22]

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

Лично я придерживаюсь мнения (если тебе интересно мое) мнение, что быстрее и дешевле разработать собственную модель учета, причем вполне шуструю, надежную и многопользовательскую, чем связываться с 1С (v 7.7). Говорю с позиции паскалишника и сиквэльщика, естесственно. Если же чел - спец в 1С, то, наверное, проще будет ориентироваться на нее. Хотя.. Больно много глючных реализаций даже там, где проект "вылизывают" спецы.

KSergey (2004-11-17 14:09:00) [20]
Интересно, в свете отгремевшей ветки про 1С, ее упомянутости уважаемым msguns и не только, а так же ввиду присутствия здесь практиков - не ответит ли кто на простой с виду вопрос: а не проще ли будет в данном конкретном случае взять готовую.. ну ту же 1С, например? О ценен пока не говорим, ведь и не знаем с чем сравнивать. Но вот с точки зрения функционала.
Просто из любопытства вопрос.

Страницы: 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »