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

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

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

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

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

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

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

0

Vourhey, ты поточнее опиши, что должно храниться в этой базе.

Сообщение от Vourhey Да дело в том, что о заказчиках речи вообще нет.

Дык есть же пользователи. Или и их тоже нет?

0

Их тоже нет

0

А что есть? Напиши блин конкретно, что должно быть в базе.

0

База. Номер контракта, телефон, выполняемые работы, сумма по каждой работе. Наличие остальных полей значения не имеют.

Добавлено через 24 секунды
Я писал это выше. Ни слова о пользователях и заказчиках.

0

Ну блин... Тогда так.
Таблицы: Работы (ИД, Наименование), Контракты (ИД, номер, телефон), Связь Работы-Контракты (ИД работы, ИД контракта, сумма).

А телефон чей указывается? Остальные данные по контракту где находятся?

0

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

0

Сообщение от Vourhey Ну, по сути, мы получаем то же самое, что и решили до этого.

Так эт чё, получается, что я зря спорил?

0

Да не вообщем-то все фигня. Это гут. Мы пришли к такому варианту. (как же я не люблю работать с БД, кто бы знал...)))

Вобщем, я еще почему изначально поместил эту тему в "алгоритмы", потому что было бы интересно узнать, какой еще можно придумать способ все это реализовать в одной таблице. Как еще можно. Без особого ущерба производительности...

0

Сообщение от Vourhey Как еще можно. Без особого ущерба производительности...

Если хранить в БД, то никак. Индексы нужно будет только куда надо навесить.

0

Сообщение от Vourhey Вобщем, я еще почему изначально поместил эту тему в "алгоритмы", потому что было бы интересно узнать, какой еще можно придумать способ все это реализовать в одной таблице. Как еще можно. Без особого ущерба производительности...

Теоритечески, можно реализовать вложенной таблицой, при условии что СУБД поддерживает NESTED TABLES, но их слишком геморройно обрабатывать...

0

Сообщение от Angry_Bobo Теоритечески, можно реализовать вложенной таблицой, при условии что СУБД поддерживает NESTED TABLES, но их слишком геморройно обрабатывать...

Это вроде только оракл умеет.
Vourhey, ты с СУБД определился?

0

Сообщение от mik-a-el Это вроде только оракл умеет.

только версии 9 и выше

0

Сообщение от mik-a-el Это вроде только оракл умеет. Vourhey, ты с СУБД определился?

Да, определился. Я без СУБД работаю sqlite. Так как, у меня особо, никаких сложных структур нет, проще встроить функции работы с БД в саму программу. И быстрее получится.
Вообщем-то, рещил сделать так, как выше. Две таблицы. Праймари кей в одной таблице - номер контракта (он же номер заказа). Делаем его Unique, а во второй ключевое поле оно же (номер контракта), но на каждую выполненную работу, и ее стоимость будет отводиться по строке. Это самый простой способ получается из всех.

0