|
|
|
Правильная организация данных
|
|||
|---|---|---|---|
|
#18+
Есть объект состоящий из 30-40 параметров. Как лучше представить его в БД: в виде одной таблицы с 40-а аттрибутами или разбить на 4-5 таблиц со связью 1-1. И соответсвенно при организации хранимой процедуры: 40 входных параметров или несколько и уже в теле процедуры разбивать их на 40 переменных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2002, 09:34:17 |
|
||
|
Правильная организация данных
|
|||
|---|---|---|---|
|
#18+
Слишком уж мало информации для ответа... Может денормализовать ? сделать три таблицы: Объекты, Параметры и их СвязиИЗначения ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2002, 09:46:45 |
|
||
|
Правильная организация данных
|
|||
|---|---|---|---|
|
#18+
Действительно, слишком мало информации. Приведу типичный пример. У объекта "организация" имеются атрибуты "Наименование", "ИНН", "Банк", "Счет", "Корсчет". Как их распределить по таблицам? Кажущееся очевидным решение (одна таблица с перечисленными полями) оказывается плохо нормализованным. Необходимо завести две таблицы - "Организации" и "Банки". Если присмотреться к атрибутам, то выясняется, что атрибут "Корсчет" - это атрибут банка , а не организации. Поэтому, имея связку между объектами "организация" и "банк", поле "Корсчет" в атрибутах организации оказывается лишним. С помощью JOIN оно извлекается из атрибутов банка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2002, 10:00:13 |
|
||
|
Правильная организация данных
|
|||
|---|---|---|---|
|
#18+
Пример: Объект ЖД билет: №поезда,Дата-время отправления,маршрут,номер билета,фамилия пассажира,вагон,место,тип,оплата и тд короче целая куча параметров. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2002, 10:10:03 |
|
||
|
Правильная организация данных
|
|||
|---|---|---|---|
|
#18+
Ну, ей богу, все равно мало! Наверное, есть еще бизнес-процессы? Кроме объекта "ЖД билет" предполагается наличие в системе других объектов? Например, "Поезда", "Ж/д станции", "Вагоны", "Пассажиры"... ? Если предполагается, то это совокупность таблиц, притом не двух-трех, а гораздо больше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2002, 10:16:51 |
|
||
|
Правильная организация данных
|
|||
|---|---|---|---|
|
#18+
Компануя вышеизложенное: если табла нормализована - пусть будет как есть, сколько бы полей не было! Ну, а если нет - надо нормализовать, ессно! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2002, 10:26:34 |
|
||
|
Правильная организация данных
|
|||
|---|---|---|---|
|
#18+
Иногда удобно хранить такие объекты в 1-й таблице с 40 атрибутами. Вопрос в том какие выборки вы будете делать, и легко ли их реализовать. Если каждый объект вы будете разбивать на 4-5 таблиц, то в конце проекта вы сами будете плавать в названиях таблиц. Работать с SP у которой 30-40 параметров неудобно. можно попробовать в качестве параметра передавать XML строку, которую прочитаете внутри SP, EXEC sp_xml_preparedocument @hdoc OUTPUT, @xml OUTPUT * ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2002, 10:28:16 |
|
||
|
Правильная организация данных
|
|||
|---|---|---|---|
|
#18+
Однозначно связи 1:1 - поля в одной таблице. Для Ж/Д билетов, тем более - жёстко фиксированный объект. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2002, 10:30:14 |
|
||
|
Правильная организация данных
|
|||
|---|---|---|---|
|
#18+
Это маленькая курсовая работа, где в постановке задачи фигурирует Организация->Касса->ЖД. В итоге набо провести анализ предметной области.Постоить модель БД. Организовать отчеты по продаже жд билетов: по типу оплаты (нал безнал),по кассиру,по направлению перевозки и классу обслуживания и тд ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2002, 10:33:51 |
|
||
|
|

start [/forum/topic.php?fid=46&gotonew=1&tid=1819542]: |
0ms |
get settings: |
5ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
21ms |
get topic data: |
6ms |
get first new msg: |
3ms |
get forum data: |
2ms |
get page messages: |
29ms |
get tp. blocked users: |
1ms |
| others: | 193ms |
| total: | 273ms |

| 0 / 0 |
