Форум: "Начинающим";
Текущий архив: 2008.11.02;
Скачать: [xml.tar.bz2];
ВнизАлгорит записей в БД накладных... Найти похожие ветки
← →
Сергей (2008-09-21 21:56) [0]Доброго времени суток.
Подскажите пожалуйста логику создания базы данных для хранения например накладных. В моем понимании таблица имеет определенные столбцы. И вот никак не могу понять как создать таблицу которая будет содержать: Номер накладной, отправителя, получателя и самое главное список позиций наклодной с ценами количеством и тд. Ведь заранее не известно сколько позиций в каждой накладной и тд. неужели придется создавать для каждого перечня отдельные таблицы!?
Если возможно примерчик в синтаксиск MySQL.
Заранее спасибо.
p.s. Я только начинаю вникать в базы данных и прошу не судить строго.
← →
MsGuns © (2008-09-21 22:53) [1]Простейший объект "Материальный документ" хранится в двух таблицах (не считая, конечно, справочников) - заголовки документа и фактуры, находящихся в отношении один-ко-многим.\
Заголовок имеет следующие обязательные атрибуты поля:
- Уникальный идентификатор записи
- Номер документа
- Дата документа
- Тип документа (приходная, расходная, возврат, списание..)
- Статус документа (проведен, задержан, незавершенный ввод..)
- Ссылка на ID контрагента (поставщика, покупателя и т.д.)
Могут еще быть :
- Суммовые реквизиты для контроля ввода фактуры
- Доп. поля, обусловленные спецификой (атрибуты доверенности, валюта, наличие НДС и др.)
- Служебные поля для фиксации таможенных данных, оплаты и др.
Фактура:
- ID строки
- ссылка на ID заголовка
- ссылка на карточку или спровчник ТМЦ (в зависимости от партионного или суммового учета на складе и в бухгалтерии)
- кол-во
- цена себестоимость без НДС
- отпускная цена (для документов на реализацию/продажу)
- НДС (ставка)
- НДС (сумма)
- Сумма без НДС (может вычисляться, но для приходов лучше хранить)
- Сумма с НДС (может вычисляться, но для приходов лучше хранить)
- доп.данные (специфика): ед.изм-я, срок реализации, упаковка
← →
Сергей (2008-09-21 23:06) [2]))) MsGuns вы не могли бы чуть по проще.... вернее как нибудь по проще объяснить связи.... (возможно не правильно формулирую)... Например две таблици в какой из них что и как это дело все связывается?
Если можно на моем примере: (Как сохранить например 10 таких записей в базе)
Накладная №1
Отправил: Иванов
Принял: Петров
Товар№1 1000шт. 10руб.
Товар№2 2000шт. 11руб.
Товар№3 3000шт. 12руб.
Товар№4 4000шт. 13руб.
← →
Правильный$Вася (2008-09-21 23:08) [3]
> Я только начинаю вникать в базы данных
неплохо бы почитать про БД в целом, про реляционные отношения и нормализацию данных в частности
тогда сабжевый вопрос отпадет сам
← →
Сергей (2008-09-21 23:17) [4]Читал инфу по MySQL... возможно читал плохо... Иногда совет в нужную сторону может избавить от чтения толмутов.
← →
Petr V. Abramov © (2008-09-21 23:59) [5]
> MsGuns © (21.09.08 22:53) [1]
> - ID строки
нахрен не надо, если, конечно, на позицию накладной никто не ссылается.
в остальном: ++
← →
DrPass © (2008-09-22 01:13) [6]
> Сергей (21.09.08 23:17) [4]
> Читал инфу по MySQL... возможно читал плохо... Иногда совет
> в нужную сторону может избавить от чтения толмутов.
Не с того ты начал. Чтение мануала по СУБД предполагает, что ты уже знаком с основами реляционных баз данных. А ты не знаком. Так что читай общую теорию. Что-то подсказать на форуме мы можем, но ты ж все равно без понимания основ программу никак не напишешь.
← →
Petr V. Abramov © (2008-09-22 01:43) [7]
> Что-то подсказать на форуме мы можем,
ага, можем.
если база не кривая, то подскажем технические вопросы по дельфям или по запросам. А если кривая, то никто не подскажет, потому что нечего/невозможно.
http://www.ozon.ru/context/detail/id/2309312/
------------------
на кривой базе нормальное приложение написать можно, но сильно дорого
← →
Юрий Зотов © (2008-09-22 02:00) [8]> Сергей (21.09.08 21:56)
Таблица 1 "Служащие"
Поля: ID (ключ), ФИО, Другие (если надо)
Таблица 2 "Товары"
Поля: ID (ключ), Наименование, Другие (если надо).
Таблица 3 "Цены" (т.к. цены могут меняться)
Поля: ID (ключ), ID_товара (ссылка на таблицу 2), Цена, Дата, Другие (если надо).
Таблица 4 "Накладные" (хранит "шапки" всех накладных)
Поля: Номер (ключ ), ID_отправителя (ссылка на таблицу 1),
ID_получателя (ссылка на таблицу 1), Дата, Другие (если надо).
Таблица 5 "Позиции накладных" (хранит все позиции всех накладных)
Поля: Номер накладной (ссылка на таблицу 4), товар (ссылка на таблицу 2), Количество, Другие (если надо).
← →
Юрий Зотов © (2008-09-22 02:02) [9]Добавление: в таблице 5 поля "Номер накладной" и "товар" образуют составной первичный ключ.
← →
Германн © (2008-09-22 02:15) [10]"Как пройти в библиотеку?
В два часа ночи!
Идиот!"
(с)
← →
Юрий Зотов © (2008-09-22 02:16) [11]> Сергей (21.09.08 21:56)
> заранее не известно сколько позиций в каждой накладной и тд. неужели
> придется создавать для каждого перечня отдельные таблицы!?
Один и тот же товар может упоминаться в нескольких накладных.
Одна и та же накладная может содержать несколько товаров.
То есть, имеем типичный случай связки "многие ко многим". Такая связка обычно реализутся отдельной таблицей, записи которой ссылаются на записи связываемых ею таблиц.
В нашем случае это таблица 5. Она реализует связку "многие ко многим" между таблицами 4 и 2.
← →
Palladin © (2008-09-22 02:55) [12]без осознания теории отношений можешь забыть о своих накладных
← →
sniknik © (2008-09-22 09:01) [13]> Одна и та же накладная может содержать несколько товаров.
и даже несколько позиций одного и того же товара. у нас было, просили так сделать т.к. весы больше 1000кг не "поднимают", а отгружать проще "партиями" по 1-й завеске, чем все в кучу, оно так и занимает 1 место в машине и принимается/проверяется в магазинах тоже так же, частями.
это кстати делает обязательным наличие ключа в (ID) в накладной (да и вообще везде, даже если изначально кажется что он не нужен), разделять позиции с одним кодом.
это вот по этому поводу
>> - ID строки
> нахрен не надо, если, конечно, на позицию накладной никто не ссылается.
изначально "нахрен", а после клиенту чтото понадобилось и если бы не это "излишество" были бы проблемы.
← →
Сергей (2008-09-22 22:20) [14]Юрий Зотов огромное спасибо за исчерпывающий ответ, расставили все по полочкам, это именно то, что мне было и нужно!
Стоит все-таки почитать теорию БД.
Petr V. Abramov спасибо за ссылку, попытаюсь осилить 1000 страничный труд, но все-таки ответ Юрия мне кажется, сократил чтение страниц на 200 точно =)
← →
MsGuns © (2008-09-22 22:36) [15]>Юрий Зотов © (22.09.08 02:00) [8]
>Таблица 1 "Служащие"
В документах на перемещение ТМЦ если и нужен, то лишь для выдачи (списания) в подотчет. В остальных случаях - фтопку !
>Таблица 2 "Товары"
Нет такой таблицы. Есть номенклатурный справочник или карточка (чаще всего и то и другое, особенно при партионном учете, когда на каждый приход своя карточка)
>Таблица 3 "Цены" (т.к. цены могут меняться)
И нахрен не нужна. Учетная цена (по чем покупалось) - какой к лешему для нее справочник ? Для отпускных цен это называется "прайс" и одной таблицей там не обойдешься
>Таблица 4 "Накладные" (хранит "шапки" всех накладных)
>ID_отправителя (ссылка на таблицу 1) ID_получателя (ссылка на таблицу
На кой ляд два поля , если в одном документе оба указаны быть не могут. Кроме того, выноска покупателей и поставщиков в разные таблицы (справочники) рано или поздно приведет к неразберихе - из-за невозможности получения развернутого баланса по контрагенту
>Юрий Зотов © (22.09.08 02:02) [9]
>Добавление: в таблице 5 поля "Номер накладной" и "товар" образуют составной первичный ключ.
А вот этого делать ктегорически нельзя !
В целом набор инструкций для какого-то "студенческий" проекта. Извини за прямоту, но это так ;)
← →
MsGuns © (2008-09-22 22:44) [16]В целом по сабжу.
Автор, похоже, элементарно не знает ЧТО нужно сделать, по крайней мере не может внятно сформулировать. Материальный учет можно (и нужно) реализовывать по-разному. Например, модель учета стройматериалов или материалов в производстве весьма отличается от учета товаров, а учет препаратов в фармации разнИтся от учета кондитерки или бакалеи (хоть и то, и другое - торговля). Малоценка вообще реализуется просто. Кроме того, есть учет складской, есть бухгалтерский и это тоже две большие разницы.
Так что налицо типичная ошибка новичка - еще не знаем куда поедем, и поедем ли вообще, а идем в магазин и выбираем велосипед. А может вообще лодка надувная понадобится ? Или дельтаплан ?
← →
Сергей (2008-09-22 22:53) [17]MsGuns конкурировать с 1С я не собираюсь, инструкций для "Студенческого проекта" вполне достаточно, вникать в складской или бухгалтерский учет пока не требуется. Вы слишком углубились, а всего лишь требовалась логика построения БД.
Ну и на будущее может кинете пару ссылок где почитать как правильно вести материальный учет, складской учет... уж до бухгалтерского думаю не доживу.
Заранее благодарен.
← →
MsGuns © (2008-09-22 23:02) [18]>Сергей (22.09.08 22:53) [17]
>MsGuns конкурировать с 1С я не собираюсь
Вы побаловаться решили, да ? А если нет, то изучите сначала предметную область. Без этого не стОит вообще садиться за проектирование. Зачем строить дом, изначально ни к чему не пригодный - просто угробить материалы ?
>Ну и на будущее может кинете пару ссылок где почитать как правильно >вести материальный учет, складской учет... уж до бухгалтерского думаю >не доживу.
Как я могу давать советы не зная ЧТО нужно сделать ? Лучше всего Вам побеседовать с гл.бухгалтером и выяснить у него, что он хочет. После этого очень рекомендую ознакомиться с уже существующими решениями, например, так пугающей Вас 1С, которая, кстати, в базовой конфигурации содержит очень много весьма полезной информации - по крайней мере ознакомившись детально с документами 1С, Вы не будете писать такую пургу в сабже
← →
MsGuns © (2008-09-22 23:06) [19]По поводу правильности ведения материального учета - см.книги не по программированию, а по бухгалтерскому учету - там все написано ясно, на русском, и нету всяких тарабарских заклинаний типа "сервер", "эскюэль" и т.д. ;)))
← →
MsGuns © (2008-09-22 23:10) [20]И последнее.
MySQL далеко не самый лучший сервер для задач подобного класса - ИМХО, стОит посмотреть в сторону более промышленных (IB/FB, MS SQL...)
← →
Сергей (2008-09-22 23:17) [21]MsGuns извиняюсь за "пургу" но по другому пока не получается.
Делфи: Хобби недалекой юнности.
Цель: Немного облегчить себе жизнь на работе.
Надоело в экселе и на бумажке вести расчеты и учет.
Объект: маааленькое производство мебели, приходится быть всем начиная от
конструктора заканчивая грузчиком.
Первый шаг уже сделал правдо коряво, но все-таки... этикетки на продукцию мы теперь через FastReport + база изделий в файле, печатаем (раньше в эксель)
p.s. Не судите строго...
← →
Сергей (2008-09-22 23:19) [22]MsGuns, MySQL мне с ним по проще разобраться... да и удаление у нас некоторое есть... поэтому хочется базу хранить в инете. MS - денег стоит.
← →
Sergey13 © (2008-09-23 08:54) [23]> [18] MsGuns © (22.09.08 23:02)
> [19] MsGuns © (22.09.08 23:06)
ИМХО, ты сильно перегнул. По твоей логике самыми лучшими базовиками должны быть бухгалтеры, потому тчо они про учет все знают. Программист тем и отличается от профильного специалиста (а он должен быть!!!), что может (должен мочь) из его разговоров построить модель, которую можно реализовать доступными программисту методами. А для этого нужно представлять себе теорию СУ[Р]БД. Именно она первична, а не предметная область.
ИМХО все исключительно.
← →
MsGuns © (2008-09-23 09:09) [24]>Sergey13 © (23.09.08 08:54) [23]
Совершенно справедливо.
Но в данной ситуации (21) я бы посоветовал все-же поискать что-либо готовое. СУБД это не батоны на формы кидать и ошибки, допущенные при проектировании, могут напрочь ниверировать все преимущества "базового" подхода перед, скажем, Экселем, в котором можно решать достаточно сложные расчетные задачи и хранить вполне "базовую" информацию.
← →
Sergey13 © (2008-09-23 09:15) [25]> [24] MsGuns © (23.09.08 09:09)
В Екселе задачи решать тоже надо уметь и сам он их не решает, если они сложнее чем 2+2.
Накидав батонов можно получить достаточно жизнеспособный продукт "для внутреннего потребления".
Никто еще наверное не начинал писать с системы уровня ERP, готовой к массовому распространению за огромные деньги через полтора месяца после начала писания.
← →
Рамиль © (2008-09-23 09:30) [26]
> Первый шаг уже сделал правдо коряво, но все-таки... этикетки
> на продукцию мы теперь через FastReport + база изделий в
> файле, печатаем (раньше в эксель)
>
> p.s. Не судите строго...
Ну так вот, почитай немного, окупится в будущем, тем что не будет коряво.
← →
Юрий Зотов © (2008-09-23 11:30) [27]> MsGuns © (22.09.08 22:36) [15]
> В целом набор инструкций для какого-то "студенческий" проекта.
Даже еще хуже. Это вообще НЕ руководство к действию, а всего лишь ОЧЕНЬ сильно упрощенный пример построения БД, на котором показана ЛОГИКА проектирования. И не более.
"Сильно упрощенный" - специально. Чтобы "лес не был заслонен деревьями". Чтобы автор мог этот пример понять. Потому что, если у человека возникла проблема с реализацией отношения "многие ко многим" (да даже и сам этот термин ему, похоже, еще незнаком), то именно такие примеры ему пока что и нужны. Потому что в реальных он просто утонет.
Так что - благодарю за критику, но... LOL!
:o)
Страницы: 1 вся ветка
Форум: "Начинающим";
Текущий архив: 2008.11.02;
Скачать: [xml.tar.bz2];
Память: 0.54 MB
Время: 0.009 c