Доброго времени суток.
Подскажите пожалуйста логику создания базы данных для хранения например накладных. В моем понимании таблица имеет определенные столбцы. И вот никак не могу понять как создать таблицу которая будет содержать: Номер накладной, отправителя, получателя и самое главное список позиций наклодной с ценами количеством и тд. Ведь заранее не известно сколько позиций в каждой накладной и тд. неужели придется создавать для каждого перечня отдельные таблицы!?
Если возможно примерчик в синтаксиск MySQL.
Заранее спасибо.
p.s. Я только начинаю вникать в базы данных и прошу не судить строго.

Простейший объект "Материальный документ" хранится в двух таблицах (не считая, конечно, справочников) - заголовки документа и фактуры, находящихся в отношении один-ко-многим.\

Заголовок имеет следующие обязательные атрибуты поля:
- Уникальный идентификатор записи
- Номер документа
- Дата документа
- Тип документа (приходная, расходная, возврат, списание..)
- Статус документа (проведен, задержан, незавершенный ввод..)
- Ссылка на ID контрагента (поставщика, покупателя и т.д.)

Могут еще быть :

- Суммовые реквизиты для контроля ввода фактуры
- Доп. поля, обусловленные спецификой (атрибуты доверенности, валюта, наличие НДС и др.)
- Служебные поля для фиксации таможенных данных, оплаты и др.

Фактура:

- ID строки
- ссылка на ID заголовка
- ссылка на карточку или спровчник ТМЦ (в зависимости от партионного или суммового учета на складе и в бухгалтерии)
- кол-во
- цена себестоимость без НДС
- отпускная цена (для документов на реализацию/продажу)
- НДС (ставка)
- НДС (сумма)
- Сумма без НДС (может вычисляться, но для приходов лучше хранить)
- Сумма с НДС (может вычисляться, но для приходов лучше хранить)
- доп.данные (специфика): ед.изм-я, срок реализации, упаковка

))) MsGuns вы не могли бы чуть по проще.... вернее как нибудь по проще объяснить связи.... (возможно не правильно формулирую)... Например две таблици в какой из них что и как это дело все связывается?
Если можно на моем примере: (Как сохранить например 10 таких записей в базе)

Накладная №1
Отправил: Иванов
Принял: Петров
Товар№1 1000шт. 10руб.
Товар№2 2000шт. 11руб.
Товар№3 3000шт. 12руб.
Товар№4 4000шт. 13руб.

>  Я только начинаю вникать в базы данных

неплохо бы почитать про БД в целом, про реляционные отношения и нормализацию данных в частности
тогда сабжевый вопрос отпадет сам

Читал инфу по MySQL... возможно читал плохо... Иногда совет в нужную сторону может избавить от чтения толмутов.

> MsGuns ©   (21.09.08 22:53) [1]
> - ID строки

нахрен не надо, если, конечно, на позицию накладной никто не ссылается.

в остальном: ++

> Сергей   (21.09.08 23:17) [4]
> Читал инфу по MySQL... возможно читал плохо... Иногда совет
> в нужную сторону может избавить от чтения толмутов.

Не с того ты начал. Чтение мануала по СУБД предполагает, что ты уже знаком с основами реляционных баз данных. А ты не знаком. Так что читай общую теорию. Что-то подсказать на форуме мы можем, но ты ж все равно без понимания основ программу никак не напишешь.

> Что-то подсказать на форуме мы можем,

ага, можем.
если база не кривая, то подскажем технические вопросы по дельфям или по запросам. А если кривая, то никто не подскажет, потому что нечего/невозможно.
http://www.ozon.ru/context/detail/id/2309312/

------------------
на кривой базе нормальное приложение написать можно, но сильно дорого

> Сергей   (21.09.08 21:56)

Таблица 1 "Служащие"
Поля: ID (ключ), ФИО, Другие (если надо)

Таблица 2 "Товары"
Поля: ID (ключ), Наименование, Другие (если надо).

Таблица 3 "Цены" (т.к. цены могут меняться)
Поля: ID (ключ), ID_товара (ссылка на таблицу 2), Цена, Дата, Другие (если надо).

Таблица 4 "Накладные" (хранит "шапки" всех накладных)
Поля: Номер (ключ ), ID_отправителя (ссылка на таблицу 1),
ID_получателя (ссылка на таблицу 1), Дата, Другие (если надо).

Таблица 5 "Позиции накладных" (хранит все позиции всех накладных)
Поля: Номер накладной (ссылка на таблицу 4), товар (ссылка на таблицу 2), Количество, Другие (если надо).

Добавление: в таблице 5 поля "Номер накладной" и "товар" образуют составной первичный ключ.

"Как пройти в библиотеку?
В два часа ночи!
Идиот!"
(с)

> Сергей   (21.09.08 21:56)  

> заранее не известно сколько позиций в каждой накладной и тд. неужели
> придется создавать для каждого перечня отдельные таблицы!?

Один и тот же товар может упоминаться в нескольких накладных.
Одна и та же накладная может содержать несколько товаров.

То есть, имеем типичный случай связки "многие ко многим". Такая связка обычно реализутся отдельной таблицей, записи которой ссылаются на записи связываемых ею таблиц.

В нашем случае это таблица 5. Она реализует связку "многие ко многим" между таблицами 4 и 2.

без осознания теории отношений можешь забыть о своих накладных

> Одна и та же накладная может содержать несколько товаров.
и даже несколько позиций одного и того же товара. у нас было, просили так сделать т.к. весы больше 1000кг не "поднимают", а отгружать проще "партиями" по 1-й завеске, чем все в кучу, оно так и занимает 1 место в машине и принимается/проверяется в магазинах тоже так же, частями.

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

Юрий Зотов огромное спасибо за исчерпывающий ответ, расставили все по полочкам, это именно то, что мне было и нужно!

Стоит все-таки почитать теорию БД.

Petr V. Abramov  спасибо за ссылку, попытаюсь осилить 1000 страничный труд, но все-таки ответ Юрия мне кажется, сократил чтение страниц на 200 точно =)

>Юрий Зотов ©   (22.09.08 02:00) [8]
>Таблица 1 "Служащие"

В документах на перемещение ТМЦ если и нужен, то лишь для выдачи (списания) в подотчет. В остальных случаях - фтопку !

>Таблица 2 "Товары"

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

>Таблица 3 "Цены" (т.к. цены могут меняться)

И нахрен не нужна. Учетная цена (по чем покупалось) - какой к лешему для нее справочник ? Для отпускных цен это называется "прайс" и одной таблицей там не обойдешься

>Таблица 4 "Накладные" (хранит "шапки" всех накладных)
>ID_отправителя (ссылка на таблицу 1) ID_получателя (ссылка на таблицу

На кой ляд два поля , если в одном документе оба указаны быть не могут. Кроме того, выноска покупателей и поставщиков в разные таблицы (справочники) рано или поздно приведет к неразберихе - из-за невозможности получения развернутого баланса по контрагенту

>Юрий Зотов ©   (22.09.08 02:02) [9]
>Добавление: в таблице 5 поля "Номер накладной" и "товар" образуют составной первичный ключ.

А вот этого делать ктегорически нельзя !

В целом набор инструкций для какого-то "студенческий" проекта. Извини за прямоту, но это так ;)

В целом по сабжу.
Автор, похоже, элементарно не знает ЧТО нужно сделать, по крайней мере не может внятно сформулировать. Материальный учет можно (и нужно) реализовывать по-разному. Например, модель учета стройматериалов или материалов в производстве весьма отличается от учета товаров, а учет препаратов в фармации разнИтся от учета  кондитерки или бакалеи (хоть и то, и другое - торговля). Малоценка вообще реализуется просто. Кроме того, есть учет складской, есть бухгалтерский и это тоже две большие разницы.

Так что налицо типичная ошибка новичка - еще не знаем куда поедем, и поедем ли вообще, а идем в магазин и выбираем велосипед. А может вообще лодка надувная понадобится ? Или дельтаплан ?

MsGuns конкурировать с 1С я не собираюсь, инструкций для "Студенческого проекта" вполне достаточно, вникать в складской или бухгалтерский учет пока не требуется. Вы слишком углубились, а всего лишь требовалась логика построения БД.

Ну и на будущее может кинете пару ссылок где почитать как правильно вести материальный учет, складской учет... уж до бухгалтерского думаю не доживу.
Заранее благодарен.

>Сергей   (22.09.08 22:53) [17]
>MsGuns конкурировать с 1С я не собираюсь

Вы побаловаться решили, да ? А если нет, то изучите сначала предметную область. Без этого не стОит вообще садиться за проектирование. Зачем строить дом, изначально ни к чему не пригодный - просто угробить материалы ?

>Ну и на будущее может кинете пару ссылок где почитать как правильно >вести материальный учет, складской учет... уж до бухгалтерского думаю >не доживу.

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

По поводу правильности ведения материального учета - см.книги не по программированию, а по бухгалтерскому учету - там все написано ясно, на русском, и нету всяких тарабарских заклинаний типа "сервер", "эскюэль" и т.д. ;)))

И последнее.
MySQL далеко не самый лучший сервер для задач подобного класса - ИМХО, стОит посмотреть в сторону более промышленных (IB/FB, MS SQL...)

MsGuns извиняюсь за "пургу" но по другому пока не получается.

Делфи: Хобби недалекой юнности.
Цель: Немного облегчить себе жизнь на работе.
        Надоело в экселе и на бумажке вести расчеты и учет.
Объект: маааленькое производство мебели, приходится быть всем начиная от
           конструктора заканчивая грузчиком.

Первый шаг уже сделал правдо коряво, но все-таки... этикетки на продукцию мы теперь через FastReport + база изделий в файле,  печатаем (раньше в эксель)

p.s. Не судите строго...

MsGuns, MySQL мне с ним по проще разобраться... да и удаление у нас некоторое есть... поэтому хочется базу хранить в инете. MS - денег стоит.

> [18] MsGuns ©   (22.09.08 23:02)
> [19] MsGuns ©   (22.09.08 23:06)

ИМХО, ты сильно перегнул. По твоей логике самыми лучшими базовиками должны быть бухгалтеры, потому тчо они про учет все знают. Программист тем и отличается от профильного специалиста (а он должен быть!!!), что может (должен мочь) из его разговоров построить модель, которую можно реализовать доступными программисту методами. А для этого нужно представлять себе теорию СУ[Р]БД. Именно она первична, а не предметная область.
ИМХО все исключительно.

>Sergey13 ©   (23.09.08 08:54) [23]

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

> [24] MsGuns ©   (23.09.08 09:09)

В Екселе задачи решать тоже надо уметь и сам он их не решает, если они сложнее чем 2+2.
Накидав батонов можно получить достаточно жизнеспособный продукт "для внутреннего потребления".
Никто еще наверное не начинал писать с системы уровня ERP, готовой к массовому распространению за огромные деньги через полтора месяца после начала писания.

> Первый шаг уже сделал правдо коряво, но все-таки... этикетки
> на продукцию мы теперь через FastReport + база изделий в
> файле,  печатаем (раньше в эксель)
>
> p.s. Не судите строго...

Ну так вот, почитай немного, окупится в будущем, тем что не будет коряво.

> MsGuns ©   (22.09.08 22:36) [15]

> В целом набор инструкций для какого-то "студенческий" проекта.

Даже еще хуже. Это вообще НЕ руководство к действию, а всего лишь ОЧЕНЬ сильно упрощенный пример построения БД, на котором показана ЛОГИКА проектирования. И не более.

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

Так что - благодарю за критику, но... LOL!
:o)