powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / такой большой проект у меня в первые
25 сообщений из 55, страница 2 из 3
такой большой проект у меня в первые
    #34087719
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ладно,вернемся к этой теме ближе к понедельку.Пятница,так сказать,сокращенный день.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34088888
CLilian
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Привет всем,
проанализировал ваши советы и решил сделать так (как на рисунке), покритикуйте пожайлуста примерчик.

Едиственное что осталось сделать и никак пока не сообразил как, это:
1. с данными по бугалтерии т.е. зарплата персонала (НДС и т.д.)
2. с данными по налогам по прибали и т.д.

Должен признаться с бугалтерии я мало знаком и буду очень рад почитать хорошую инфу про это дело. Я так поня что данные по бугалтерии храняться в отдельной таблице с ссылкой скажем на т.Operations но для опредиления полей мне надо почитать инфу бугалтерскового дела. Если можите чем нибуть помочь, хоть ссылочку или идею как реализовать то я буду очень признателен.

С уважением,
Лилиан.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34089002
I_one
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А на чём пишете клиентскую часть если не секрет ? ... И почему сервер выбран MS SQL?
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34089221
CLilian
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
I_oneА на чём пишете клиентскую часть если не секрет ? ... И почему сервер выбран MS SQL?
Пищу я на ВБ 6.0, как я понял MS SQL предлагает хорошую систему защиты.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34089449
Фотография Папа Игорь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Здравствуйте!
Начну с простого – с игры. Возьмем два блюдечка и положим в одно 10-15 зернышек риса. Рис – это наши «УЧЕТНЫЕ ЕДИНИЦЫ». Я прошу отгрузить 3 учетные единицы. Для этого из первого блюдца возьмем 3 зернышка и положим во второе. Я прошу отгрузить 5 учетных единиц. Сделаем тоже, но переложим 5 зернышек. Все – учетный период закончился.
Для того чтобы узнать, сколько учетных единиц у меня осталось, я их посчитаю в первом блюдце, а для того чтобы узнать, сколько я отгрузил – буду считать во втором.
Это мой ключевой принцип учета ТМЦ (на нем построены работающие много лет системы).
Некоторые моменты:
- учет ведется в «учетных единицах» на запись, т.е. каждая запись – это описание одной «учетной единицы», поле «количество» отсутствует
- в большинстве систем тип ключевого поля для «заголовочной части» - это datetime, а в таблицах Warehouse и GoodsMovement он составной из внешнего на заголовок и простого инкремента в пределах внешнего ключа.
- если надо эти две таблицы денормализуются и из заголовочной части к ним мигрируют атрибуты склада и т.п.
- в рабочих процессах все многоходовые операции (например, принять с трех складов поставщика некоторые ТМЦ и оприходовать их на 8 складов этого филиала) в композитной обработке приводятся к атомарным «приход – расход» и заносятся в таблицы.
Что позволяет:
- легкость и быстрота получения отчетных данных
- элементарная организация учета по FIFO, LIFO, индивидуальному и среднему
- масштабируемость от «я торгую» до «с нами весь мир»
Примечания:
- описан подход, а не набросок реализации
- конечно, реализация учитывает и журналы отклонений, и «человечески» фактор и др. важные и такие «интересные» моменты.
- критиковать не надо, т.к. задача была ознакомить с альтернативным апробированным подходом, а не вступать в полемику.
Успехов.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34089492
CLilian
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Папа Игорь
Некоторые моменты:
- в большинстве систем тип ключевого поля для «заголовочной части» - это datetime, а в таблицах Warehouse и GoodsMovement он составной из внешнего на заголовок и простого инкремента в пределах внешнего ключа.
Уважаемы Папа Игорь я не совсем понял принцип описаный выше, если не трудно обесните пожалуйста еще раз.

С уважением,
Лилиан.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34089717
Простой и естественный подход у Папы Игоря - учитывать все материалы, как так называемые "основные средства" - в количестве=1. Тогда "количество" действительно не нужно. Только одна проблемка. Чтобы учет был бы полноценным, необходима физическая идентификация. Иначе никакой "партионный учет" и "прослеживаемость" будут невозможны. Но тут нам поможет Левша. Он придет, и проидентифицирует каждое рисовое зернышко.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34091113
Фотография Папа Игорь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Здравствуйте!
Уважаемый Андрей Леонидович, а как Вы идентифицируете партии?
А в внутри партии ТМЦ «обезличены»?
Ответив на эти вопросы для себя, Вы увидите, что предложенный мной подход, решает и эти задачи. Левша не нужен, не нужна и «физическая идентификация» (а что это такое?), необходимо отойти от стереотипов и все будет ОК.
Повторюсь:
- «живые» системы работают на этом принципе
- мое сообщение не для полемики
- этот подход НЕ ЕДИНСТВЕННО верный

Для Лилиан.
В данное время очень занят, но может ближе к вечеру, попробую прояснить для Вас этот подход.
Успехов.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34091523
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Глянул-теперь больше походит на правду,но такие вопросы:
1. сущность Контракт (Заказ) Вы решили не выделять,хотя вначале про нее спрашивали?В чем причина?
2. Вам вроде бы все говорили,что from и to может быть как складом,так и человеком (к слову о едином реестре).Вы все равно сделали ссылку только на склад...
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34092258
Уважаемый Папа Игорь, я давно отошел от стереотипов. Но теперь, следую Вашему совету, отойду от них еще дальше. Однако нужно понимать, что без физической идентификации партий, независимо от нашего с Вами расстояния от стереотипов, ни о каком "партионном учете" и "прослеживаемости" не может быть и речи.
"Внутри" Вы говорите ?
Пример. Получив 5 коробочек сахара (по 1 кг), можно "оприходовать" это как 5 партий, наклеив на коробочки ид. партий (и/или ШК):
234,235,236,237,238.
А можно "оприходовать" это как 1 партию, наклеив:
234,234,234,234,234.
"Внутри" получается по-разному. В первом случае идентифицирован "каждый килограмм". А "внутри" кусочки сахара, а "внутри кусочков" песчинки. И как же без Левшы физически идентифицировать каждую песчинку, если это нужно ?
И о каких именно "стереотипах" Вы говорите ? Возьмите теперь из коробочки 236 (первый "вариант учета"), например, 0.7 кг сахара. А теперь возьмите 0.7 кг сахара из одной из коробочек 234 (второй "вариант учета"). И поразмышляйте о разнице, отойдя от стереотипов уже бесконечно далеко.
Мы с Вами, надеюсь, понимаем друг друга. Осталось только Вам пояснить Ваш подход CLilian.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34092268
CLilian
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ShtockГлянул-теперь больше походит на правду,но такие вопросы:
1. сущность Контракт (Заказ) Вы решили не выделять,хотя вначале про нее спрашивали?В чем причина?
Я выделяю заказ при создания документа. Сделал я это потому что при любой операции делаеться документ, вот я и присоединил к документу статус для опредиления его и всех заказов в нем.
Вопрос: может есть и другие варианты?
Shtock2. Вам вроде бы все говорили,что from и to может быть как складом,так и человеком (к слову о едином реестре).Вы все равно сделали ссылку только на склад...
Если чесно я при проектировании упустил эту важную деталь, буду думать.

С уважением,
Лилиан.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34092403
Фотография Папа Игорь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Для Лилиан.
Все нижеизложенное максимально упрощено, служит для пояснения концепции и для реальной системы в таком виде не приемлемо, но МОЖЕТ служить отправной точкой к размышлению.
Вначале немного анализа.
Учетную систему (УС) можно рассматривать как некий процессор, обрабатывающий события в бизнесе. Произошло событие важное для бизнеса – УС зафиксировала его и соответственно отреагировала.
Поэтому приготовим табличку для событий.
Код: plaintext
1.
2.
3.
4.
CREATE TABLE dbo.BusinessEvent(
	EventDate datetime NOT NULL DEFAULT (GETDATE()),
	AgentID int NOT NULL,
	EventID int NOT NULL,
 CONSTRAINT PK_BusinessEvent PRIMARY KEY CLUSTERED(EventDate ASC))

EventDate - дата/время события служит ключем
AgentID - контрагент, в случае "внутреннего" события это сам хост
EventID - вид события
Для прихода ТМЦ таблица такая:
Код: plaintext
1.
2.
3.
4.
5.
CREATE TABLE dbo.Warehouse(
	RefKey int IDENTITY( 1 , 1 ) NOT NULL,
	EventDate datetime NOT NULL,
	ProductID int NOT NULL,
	Amount int NOT NULL,
 CONSTRAINT [PK_Warehouse] PRIMARY KEY(RefKey ASC))
Для «ухода» такая:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
CREATE TABLE dbo.GoodsMovement(
	RefKey int NOT NULL,
	EventDateOut datetime NOT NULL,
	AmountOut int NOT NULL,
	ProductID int NOT NULL,
	EventDateIN datetime NOT NULL,
	AmountIn int NOT NULL,
 CONSTRAINT [PK_GoodsMovement] PRIMARY KEY(RefKey ASC))

Теперь поиграем (обработка ошибок, транзакции и т.п. не показываются):

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
140.
141.
142.
143.
144.
145.
146.
147.
148.
149.
150.
151.
152.
153.
154.
155.
156.
-- от контрагента №3 20.10.2006 14:10:02 поступили ТМЦ двух видов
-- 1. № 1 10 уч.ед. на сумму 100
-- 2. № 2 15 уч.ед. на сумму 180
DECLARE @EventDate datetime
DECLARE @Counter int
DECLARE @Qty int
DECLARE @Rest int
DECLARE @Amount int

SET @EventDate = CONVERT(datetime, '20061020 14:10:02',  113 )
INSERT INTO BusinessEvent VALUES(
	@EventDate
	,  3 
	,  1 
	)
-- товар № 1 
SET @Rest =  100 
SET @Qty =  10 
SET @Amount = CONVERT(int, @Rest / @Qty)
SET @Counter =  1 
WHILE @Counter < @Qty
	BEGIN
		INSERT INTO Warehouse VALUES(
			@EventDate
			,  1 
			, @Amount
		)
		SET @Rest = @Rest - @Amount
		SET @Counter = @Counter +  1 
	END
INSERT INTO Warehouse VALUES(
	@EventDate
	,  1 
	, @Rest
)

-- товар № 2
SET @Rest =  180 
SET @Qty =  15 
SET @Amount = CONVERT(int, @Rest / @Qty)
SET @Counter =  1 
WHILE @Counter < @Qty
	BEGIN
		INSERT INTO Warehouse VALUES(
			@EventDate
			,  2 
			, @Amount
		)
		SET @Rest = @Rest - @Amount
		SET @Counter = @Counter +  1 
	END
INSERT INTO Warehouse VALUES(
	@EventDate
	,  2 
	, @Rest
)
-- следующая поставка
-- от контрагента №1 20.10.2006 15:18:33 поступили ТМЦ 
-- 1. № 1 8 уч.ед. на сумму 75
SET @EventDate = CONVERT(datetime, '20061020 15:18:33',  113 )
INSERT INTO BusinessEvent VALUES(
	@EventDate
	,  1 
	,  1 
	)
-- товар № 1 
SET @Rest =  75 
SET @Qty =  8 
SET @Amount = CONVERT(int, @Rest / @Qty)
SET @Counter =  1 
WHILE @Counter < @Qty
	BEGIN
		INSERT INTO Warehouse VALUES(
			@EventDate
			,  1 
			, @Amount
		)
		SET @Rest = @Rest - @Amount
		SET @Counter = @Counter +  1 
	END
INSERT INTO Warehouse VALUES(
	@EventDate
	,  1 
	, @Rest
)

-- отгрузим контрагенту № 5 21.10.2006 10:00:00
-- 2 уч.ед. ТМЦ № 1 на сумму 30
-- допустим учет ведется по LIFO

DECLARE @ProductID int
DECLARE @RefKey int

SET @EventDate = CONVERT(datetime, '20061021 10:00:00',  113 )
INSERT INTO BusinessEvent VALUES(
	@EventDate
	,  5 
	,  2 
	)
-- товар № 1 
SET @ProductID =  1 
SET @Rest =  30 
SET @Qty =  2 
SET @Amount = CONVERT(int, @Rest / @Qty)
SET @Counter =  1 

WHILE @Counter < @Qty
	BEGIN
		SET @RefKey = (
				SELECT   W.RefKey
				FROM (SELECT TOP  1  * FROM Warehouse ORDER BY EventDate DESC) AS W
				WHERE W.ProductID = @ProductID
				)
		INSERT INTO GoodsMovement ( RefKey
      , EventDateOut
      , AmountOut
      , ProductID
      , EventDateIN
      , AmountIn
		)
		SELECT  @RefKey
				, @EventDate
				, @Amount
				, W.ProductID
				, W.EventDate
				, W.Amount
		FROM Warehouse W
		WHERE W.RefKey = @RefKey

		DELETE FROM Warehouse WHERE RefKey = @RefKey

			SET @Rest = @Rest - @Amount
			SET @Counter = @Counter +  1 
	END
	SET @RefKey = (
			SELECT   W.RefKey
			FROM (SELECT TOP  1  * FROM Warehouse ORDER BY EventDate DESC) AS W
			WHERE W.ProductID = @ProductID
			)

	INSERT INTO GoodsMovement ( RefKey
   , EventDateOut
   , AmountOut
   , ProductID
   , EventDateIN
   , AmountIn
	)
	SELECT  @RefKey
			, @EventDate
			, @Amount
			, W.ProductID
			, W.EventDate
			, W.Amount
	FROM Warehouse W
	WHERE W.RefKey = @RefKey
	
DELETE FROM Warehouse WHERE RefKey = @RefKey

Вот, пожалуй, и все. Если надо учитывать склад, матответственных и т.п. просто добавляем нужные атрибуты в соответствующие таблицы.
Делал все быстро (хотел успеть до конца дня), так что если где не стыкуется, то сорри.
Успехов.

P.S. Увидел пост от Андрея Леонидовича и понял, что писатель из меня никакой (хороший писатель мысль свою доносит до «самых до окраин»).
Уважаемый Андрей Леонидович, «учетная единица» - это у меня не от бедности словарного запаса. Это ограничение. И 0,7 уч.ед. быть НЕ МОЖЕТ.
В каждом конкретном бизнесе это суть РАЗНЫЕ величины.
В Вашем примере для сахара ( Вы сладкоежка?) это может быть и пачка, и кусочек. Ограничение одно – атомарность. Т.е. дальнейшее «деление» невозможно (не по физической причине, а по бизнес-правилам).
Получил тонну гравия (я камнеед?), а учет веду в килограммах, значит записываю 1000 уч.ед. гравия.
Отсюда и мой вопрос про партионность и «обезличенность» внутри партии. И совет (только совет) отойти от стереотипов (не уйти в бесконечность). Наличие в моей РАСХОДНОЙ накладной строки вида “0,5 тн. гравия” не обязательно в ТАКОМ ЖЕ ВИДЕ будет отражено в таблицах.
Ваш подход, каков бы он ни был, имеет право жить и решать Ваши задачи.
Мой подход – «аналогично» (с)

Желаю здравствовать.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34092415
Фотография Папа Игорь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В последнем абзаце кода надо так (оттенил исправление):
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
	INSERT INTO GoodsMovement ( RefKey
   , EventDateOut
   , AmountOut
   , ProductID
   , EventDateIN
   , AmountIn
	)
	SELECT  @RefKey
			, @EventDate
			, @Rest
			, W.ProductID
			, W.EventDate
			, W.Amount
	FROM Warehouse W
	WHERE W.RefKey = @RefKey
	
DELETE FROM Warehouse WHERE RefKey = @RefKey
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34092494
CLilian
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Спасибо большое Папа Игорь за очень поеснительный пример.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34093625
CLilian
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Здраствуйте,
Папа Игорь у меня поевились 2 вопроса к вам и вот какие:
1. Таблицы BussnessEvent, Wherehouse и GoodsMoment можно и нужно связать между ними связями?
2. В вашем примере я заметил что поле Amount тип данных INT а есть ли смысыл менять его на MONEY или это зависит от конкретной задачи?

С уважением,
Лилиан.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34095561
Фотография Папа Игорь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Здравствуйте!
Ответы:
1. Я предложил Вам идею (подход). Реальное проектирование возможно только после сбора требований к Вашей системе. Поэтому ни о каких либо "связях" и "таблицах" речь не идет. На полях замечу, что "связи" - это бизнес-правила (ограничения) на данные и принять решение об их "количестве и качестве" возможно только после анализа задачи. Иногда эти ограничения кодируют на клиенте.
2. Зависит от задачи. Есть системы где деньги ХРАНЯТСЯ в типе int, в другой системе в money.
Успехов.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34095814
Все было бы хорошо, Папа Игорь, но у меня нет никакого подхода (откуда же взяться стереотипам, что за стереотипы такие ?). А недостаточность (для партионного учета и прослеживаемости) Вашего подхода я продемонстрировал. Конечно, она связана не со стереотипами (ни в коем случае !), а с осознанными ограничениями Вашего подхода. И, конечно, тоже желаю здравствовать.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34097341
Фотография Папа Игорь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Здравствуйте.
Отвечаю не для того чтобы мое сверху было.
Уважаемый Леонид Андреевич, я в смятении. Мое косноязычие не позволило донести ПРОСТОТУ и ЛОГИЧНОСТЬ моего подхода. Призываю на помощь строгий и великий SQL.
Из Вашей структуры хранения легко получить мою. Обратную операцию провести тоже легко. А главное - БЕЗ ПОТЕРИ ИНФОРМАЦИИ. Это очень важно, Леонид Андреевич, очень! На этом стоят правила декомпозиции и композиции. Информация не должна терятся.!!!
Делаем такой запрос к таблице Warehouse (Вы же понимаете ее структура – это пример):
Код: plaintext
1.
2.
3.
4.
5.
SELECT ALL EventDate
	, ProductID
	, COUNT(*) AS Qty
	, SUM(Amount) AS Total
FROM Warehouse
GROUP BY EventDate, ProductID
Выводятся остатки на момент последней зафиксированной сделки.
Результат имеет ТРАДИЦИОННУЮ структуру (плюс ЛЮБЫЕ необходимые атрибуты для, многократно упомянутых Вами, партионности и прослеживаемости).
Вы можете спросить, а зачем тогда эти пляски. Это позволяет реляционно (без курсоров) обрабатывать (корректировать) прошлые сделки (да-да и в этом есть неообходимость), прозрачно менять подходы к расчету себестоимости проданных товаров, прослеживать местонахождение ЕДИНИЦЫ товара вплоть до ячейки на стеллаже и т.д.
Дальнейшие упражнения с таблицами Вы можете выполнить сами. Это убедит Вас в «однонаправленности» наших рассуждений. Просто я решил пройти немного дальше в декомпозиции. Подчеркну еще раз – ИНФОРМАЦИЯ НЕ ТЕРЯЕТСЯ.
Желаю Вам всего и только хорошего.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34098304
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Папа ИгорьИскренне восхищен
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34098933
В смятении, уважаемый Папа Игорь, вовсе не обязательно находиться.
Если сахар Вас не устраивает, так здесь уже учитывали спирт. И я тогда предложил приблизительно "Ваш подход" (см. тему "Операция распаковки партии товара").
Вы отпейте (или отлейте - по нынешним "отравленным временам") спирта из одного конкретного ведра при любой удобной для Вас "учетной единице", и поясните что получится у Вас в учете (я уж не прошу "вырезать кусок некоторой конфигурации из листа металла, и учесть остаток"). Хоть реляционно, хоть не реляционно.
Будьте здоровы.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34099050
Фотография Папа Игорь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я хотел дать им крылья! Они думали – их валяют в перьях. (с)
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34099256
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
оригинально! Я тоже в восхищении. 40 тыс. номенклатуры по 100 тыс каждого наименования. Единица учета - грамм. О чем вообще речь идет? Это шутки сейчас такие? Тогда спасибо. Действительно весело.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34100327
Фотография Папа Игорь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Здравствуйте!

"... 40 тыс. номенклатуры по 100 тыс каждого наименования. Единица учета - грамм. ..."

Я бы подекомендовал прочесть ВНИМАТЕЛЬНО весь топик (только без обиды, ладно?), ибо Ваше высказывание "в никуда". Ни граммов, ни килограммов, ни пачек в моем подходе нет, господа. А есть, заданная бизнес-правилами, ЕДИНИЦА УЧЕТА.
В конце 90-х я проектировал базу для одной совместной фирмы. В Испании у нее работал "свечной заводик" (с), а на Украине она торговала произведенной продукцией плюс еще чем-то, включая канцтовары.
Среди прочих товаров был некий вид шампуня. Так вот он учитывался полудюжинами.
Шесть флаконов были залиты пластиком и в таком виде отпускались потребителям. Это была НЕДЕЛИМАЯ далее учетная единица. В регистрах учета хранилось не шесть шт., а одна запись на единицу учета.
Другая контора. Торговля финской наждачной бумагой. В пачке 50 листов. Единица учета - пачка. Листами фирма не торговала - только пачками.
Третья контора. Сигареты. Единица учета - блок. Получали вагонами - учитывали блоками.
Повторюсь. Единица учета задается не ФИЗИЧЕСКИМИ параметрами, а БИЗНЕС-ПРАВИЛАМИ.
Надеюсь приведенные примеры окончательно убрали "непонятку". И, конечно, как и всякий другой подход, этот имеет ГРАНИЦЫ ПРИМЕНИМОСТИ.
В испанской фирме были такие объемы:
Номенклатура - около 12000
Средний запас на ед. - 400-450
Таблица типа Warehouse содержала около 5 млн. записей. 32 байт на запись. Размер таблицы примерно 150 метров.
В таблицу типа GoodsMovement за месяц заносилось около 2,2 млн. записей. Размер записи 52 байт. Это около 100 метров.
Господа, это не те размеры и объемы, чтобы копья ломать. Хотя до меня доходили слухи, что одна контора на ГОРАЗДО больших объемах применяла этот подход.
Всем успехов и процветания.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34102158
ГРАНИЦЫ ПРИМЕНИМОСТИ. Это хорошо, Папа Игорь. И они вполне понятны. Торговля. Причем оптовая (ни спирта не отлить, ни колбасы не отрезать). И некоторые другие границы. Да, мы тут с iscrafm, наверное, зациклились на производстве. Вы правы, Папа Игорь, ГРАНИЦЫ ПРИМЕНИМОСТИ делают просто чудеса, в плане использования бесконечного множества подходов в зависимости от бесконечного множества границ.
Жизнь разнообразна, так сказать.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34102191
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Папа ИгорьЯ бы подекомендовал прочесть ВНИМАТЕЛЬНО весь топик (только без обиды, ладно?), ибо Ваше высказывание "в никуда". Ни граммов, ни килограммов, ни пачек в моем подходе нет, господа. А есть, заданная бизнес-правилами, ЕДИНИЦА УЧЕТА.
Да какие обиды. Я же и говорю единица учета - грамм ;) В общем любой, какой только есть сыпучий, льющийся, режущийся и т.п. запас. Слишком ограничено и сомнительный выигрышь.... "не так как обычно".
...
Рейтинг: 0 / 0
25 сообщений из 55, страница 2 из 3
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / такой большой проект у меня в первые
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]