Метод многомерного моделирования
Создание таблиц в базе данных
Схема склада. Дайте совет.
Ссылка на сообщение Ссылка включая название темы Ссылка URL x. Топик располагается на нескольких страницах: Хочу написать приложение на java-ве которое соединялось бы с базой для осуществления запросов, добавление удаление данных о товаре который храниться на складе. В качестве СУБД - mysql. Для хранения данных создал схему которую предполагаю использовать если она верна В качестве примера взял задание одного из учебныx центров: Поставщиков и Получателей товаров. Система учета должна хранить всю историю работы с товаром. Shtock, Это учебная задача? Если учебная, то можете лепить что угодно, не спрашивая ничьих советов А если боевая, то структура никуда не годится. К примеру, количество не должно храниться в таблице предметов товаров , а должно быть на месте хранения. Там же должно быть состояние предмета статус. Рекомендую идентифицировать такие состояния, как: Все мои скромные рассуждения базируются на более чем летнем опыте разработки и эксплуатации по сей день подобных систем учета Тема перенесена из форума "Сравнение СУБД". Чувсвую что задача учебная. Самый костяк склада, без которог - никак: Справочник продуктов, как правило, иерархический. Документы по движению приход-расход. Товары в Документах по движению. Таблица остатков на даты. Таблица остатков на даты и таблицы движения, товары по движению взаимосвязаны. Остаток на любую дату можно получить по движению как сумма всех приходов - сумма всех расходов. Но при накоплении движений такие расчеты начинают тормозить. Поэтому в практических целях на отчетные даты фиксируют посчитанный остаток. Тут же возникает вопрос закрытия периодов, правки в закрытом периоде - его надо продумать как решать. Поставщики, потребители, заказы, накладные - следующий слой учета, усложнение модели. Учет цены себестоимости , расчет прибыли - тоже следующее усложнение. Еще где-то усложенние - единицы измерения, комплектация и разукомплектация. Купили 3 ящика по 12 бутылок, продали 4 бутылки и 17 бутылок. На форуме по аксесу была специально большая тема про склад с ориентацией для новичков, с готовыми базами. Old Nick Member Откуда: К сообщению приложен файл Учетная система. Old Nick Вот тут почитай. Hofmann автор Таблица остатков на даты и таблицы движения, товары по движению взаимосвязаны. Советы и критика приветствуется. Остатки не по складу и не по товару, а по товару и по складу одновременно. Не надо хранить остатки. Хранить предварительно посчитанные остатки нужно только при очень больших объемах, от миллиарда записей. Old Nick Остатки не по складу и не по товару, а по товару и по складу одновременно. Hofmann, Сделайте такую таблицу, а дальше пляшите от нее create table TRegister ID int identity 1 , 1 primary key clustered , Date datetime , FromStockID int , ToStockID int , WareID int , UnitID int , Quantity int , OperationID int go Это регистр учета. В нем регистрируете все приходы, расходы, перемещения. Date datetime, -- Дата операции FromStockID int, -- Со склада ToStockID int, -- На склад WareID int, -- Товар UnitID int, -- Единица измерения Quantity int, -- Количество OperationID int -- Операция Приход, расход, перемещение , можно ссылку на документ писать Stock - это единый справочник всех хозяйствующих субъектов, то есть склады, ячейки, зоны, организации, филиалы и мат-отв. Old Nick, По этой таблице считайте остатки. Если определили остаток по ячейкам, то остаток по камере должен быть равен сумме остатков по ячейкам. Hofmann, А где тут таблица товаров? Hofmann, резервирование есть, снятия с резерва нет. Организации, филиалы, склады, отв. Для различающихся признаков можешь сделать доп. То есть должна быть возможность в поле FromStockID запихнуть и склад и мат. Соответственно поле OrganizationID в таблице Products будет означать только юрлицо. Фактически это будет ведение учета в разрезе юрлиц. Можешь его пока убрать. Таблицу субъектов сделай иерархической. А то что ты там нагородил убери. Таблицу Products переименуй в Register, потому что это не таблица продуктов, а таблица регистрации хоз. Тоже проектируем базу учета, есть несколько вопросов: Учет партий товара приход по разной стоимости, но одного вида товара , как понять из какой партии расходовали товар? Учет вложенности товара, к примеру один товар содержит несколько товаров внутри себя и одновременно находится в двух других товарах. БД не по товарам, но смысл учета остается, бухгалтерия тоже. Dimitry Sibiryakov Member Откуда: ShurikSNZ как понять из какой партии расходовали товар?
Примеры программ поддержки малого и среднего бизнеса
Состаренная бумага своими руками
Скачать программу делать коллажи из фотографий
Изменение цветовой схемы
Город курган на карте россии какая область
Патч корд 5м