Какой вариант для хранения данных выбрать?

Есть прога. Работает с БД (не суть важно для вопроса с какой). Программа принимает различные данные от пользователя. Номер контракта, дом телефон и т. д.. Все эти данные потом должна заноситься в БД.
Планирую в таблице примерно такую структуру:

| №_контракта | дом_тел | . . . | . . .

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

Пока мне в голову приходит только: сделать одно поле для выполняемых работ. Задать ему определенный формат. Например, сначала текст "вид работы", потом какой нибудь специальный знак, а за ним цена работы. Тогда нужно читать строку, парсить... Бррр.

Дублировать записи не пойдет. Создавать для каждой выполненной работы отдельное поле тоже. Т. к., будет куча пустых полей. Да еще цена...

Что можно еще придумать?

0

А таблицу с видами и стоимостью работ сделать и привязать ее к основной по внешнему ключу - не вариант?

0

дело в том, что виды работ не фиксированы. Стоимость тоже вводится самим пользователем.

Например. Есть контракт номер 0000, ему выполнили работу 1, работу 2 и 3. стоимость 1 - 100, 2 - 200, 3 - 300.

И есть контракт 1111, ему выполнили работу 1 стоимостью уже 350, а не 100, как в предыдущем, работу 5 стоимостью 400.

Имена работ: 1, 2, 3, 5 вводятся пользователем и могут быть любыми.
Что мы тогда должны хранить в еще одной таблице?

0

Структура базы должна быть такой.
Таблицы: Пользователи, Контракты, Работы
Таблица Контракты ссылается на таблицы Пользователи (бизнес-правило о контрактах пользователя) и таблицу Работы (бизнес-правило о работах по контракту). В случае, если по контракту может осуществляться несколько работ, то вводится таблица связей, содержащая записи со ссылками на контракт и выполняемые по нему работы с их стоимостью. Если контракт может выполняться несколькими пользователями, то тоже вводится соответствующая таблица связей.

0

Думаю что надо хранить эти данные ввиде связанных таблиц
например в одной таблице хранятся все данные о работнике плюс его ID
( primery key) и для каждого рабочего создаем дочернюю таблицу, в которой
будет также храниться ID рабочего и данные о выполняемых работах

0

Сообщение от Sergei и для каждого рабочего создаем дочернюю таблицу, в которой будет также храниться ID рабочего и данные о выполняемых работах

Не многовато таблиц? Учите теорию баз данных.

0

Сообщение от Vourhey дело в том, что виды работ не фиксированы. Стоимость тоже вводится самим пользователем. Например. Есть контракт номер 0000, ему выполнили работу 1, работу 2 и 3. стоимость 1 - 100, 2 - 200, 3 - 300. И есть контракт 1111, ему выполнили работу 1 стоимостью уже 350, а не 100, как в предыдущем, работу 5 стоимостью 400. Имена работ: 1, 2, 3, 5 вводятся пользователем и могут быть любыми. Что мы тогда должны хранить в еще одной таблице?

Храним имя работы, стоимость; связь с основой по № контракта( это в грубом виде)

0

Сообщение от Angry_Bobo Храним имя работы, стоимость;

А если стоимость работы будет зависеть от контракта и исполнителя?
Читайте пост 4.

0

Сообщение от mik-a-el А если стоимость работы будет зависеть от контракта и исполнителя? Читайте пост 4.

имеется в виду стоимость введенная пользователем.
Читайте посты 1,3...

0

Сообщение от Angry_Bobo имеется в виду стоимость введенная пользователем.

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

Таблицы: Пользователи, Контракты, Работы и таблица связей Пользователь - Контракт - Работа - Стоимость работы (числовое поле).

0

Анализируязагвоздку Vourhey, прихожу к выводу, что достаточно так:

Таб1 (№ контракта (PK), дом. тел,.....,...)
Таб2 (№ контракта (FK), работа, сумма )

ни больше ни меньше...

0

Сообщение от Angry_Bobo Таб1 (№ контракта (PK), дом. тел,.....,...)

Что за дом, тел? Если исполнителя, то получаем дублирование данных в базе по пользователям и возможное нарушение их целостности.

Сообщение от Angry_Bobo Таб2 (№ контракта (FK), работа, сумма )

Получаем дублирование данные по работам, соответственно и возможное нарушение целостности данных.

Добавлено через 1 минуту 45 секунд
Емае, люди, не позорьтесь)) Изучите хотя бы основы проектирования баз данных.

0

Сообщение от Angry_Bobo Храним имя работы, стоимость; связь с основой по № контракта( это в грубом виде)

То есть,
| job_name | cost |
Где будет номер контракта? Хотя, сделать тогда примерно так вторую таблицу:
| contract_num | job_name | cost |
Соответственно, в первой у нас тоже будут номера контрактов, но записи не будут повторяться. Вобщем, что-то в таком роде тогда:

Инфа о заказчике:
| contract_num | phone_num | surname |

Инфа о работах:
| contract_num | job | cost |

норм?
Я системщик. Понимание БД у мя несколько своеобразное )))

Добавлено через 1 минуту 53 секунды
Блин, я опоздал.
Angry_Bobo, мнения сошлись.

Добавлено через 32 секунды
mik-a-el, я не могу придумать, как здесь без дублирования номеров контрактов. ИМХО, никак.

0

Сообщение от Vourhey Инфа о заказчике: | contract_num | phone_num | surname | Инфа о работах: | contract_num | job | cost | норм?

Почти... только лучше сделать так:

Инфа о заказчике:
act_id| contract_num | phone_num | surname |

Инфа о работах:
act_id| job | cost |

где act_id первичный ключ в инфе о заказчиках и внешний в инфе о работах... соотв. связь м/д таблицами по полю act_id

0

Angry_Bobo, ответьте на мои вопросы по структуре базы, а то я уже устал смеяться, читая ваши посты

Добавлено через 2 минуты 50 секунд

Сообщение от Vourhey mik-a-el, я не могу придумать, как здесь без дублирования номеров контрактов. ИМХО, никак.

Да что тут непонятного?
Есть 3 таблицы: данные о пользователях (ИД, номер телефона, адрес и т.п.), данные о контрактах (ИД, суть контракта) и данные о работах (ИД название работы, суть работы). Есть таблица, задающая связи между пользователем (внешний ключ на ИД пользователя), контрактом (внешний ключ на ИД контракта) и работой (внешний ключ на ИД работы) и задающая стоимость этой связки. Эта структура покрывает весь ваш функционал.
Блин, элементарная задача, а ошибок понаделано...

Добавлено через 2 минуты 50 секунд
Angry_Bobo, хотелось бы выслушать доводы против этой структуры и за вашу

0

Сообщение от mik-a-el Angry_Bobo, ответьте на мои вопросы по структуре базы, а то я уже устал смеяться, читая ваши посты

mik-a-el,речь в топикстарте шла о хранении данных о выполняемых работах, а не о нормализации всей предметной области., может это и не нужно в данной ситуации, а вы в человека путаете...

0

Но это не значит, что нужно допускать подобные просчеты при проектировании базы. Или вы всегда так относитесь к проектированию баз?
Я таки жду ответы на свои вопросы.

0

Я вообще думал, что по постановке,нужно запихать все в одну таблицу и поэтому аккуратно предложил такой вариант. А с точки зрения нормализации, mik-a-el , вы абсолютно правы и с такой моделью я вполне согласен...

0

Да, мы наверно по-разному поняли суть задачи. Я понял то, что необходимо создать базу, где необходимо хранить данные о пользователях, их контрактах, работах и стоимости работ. Собственно и структура базы была под именно такую задачу.

0

Да дело в том, что о заказчиках речи вообще нет. Здесь главное - это номер контракта.

0