Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
08.06.2006, 09:26
|
|||
|---|---|---|---|
|
|||
Организация ключевого поля |
|||
|
#18+
Необходимо хранить в БД сведения о некой сети Сеть состоит из пролетов у кот. есть начальный узел и узел направления (ID узлов известны и понятны юзеру).Т. о. один пролет описывается двумя записями в таблице Узел____Направл 1____________2 2____________1 2____________3 3____________2 Есть два вида данных общие для пролета (например, дата запуска в работу) и уникальные для каждого узла (например серийный номер оборудования). Понятно что, общие данные необходимо выделить в отдельную таблицу "Пролеты", смущает как задать ключевое поле для такой таблицы и механизм ввода данных, т.е. чтобы юзер вводя новую пару Узел/Направл автоматом получал одну запись в табл "Пролеты" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
08.06.2006, 10:53
|
|||
|---|---|---|---|
Организация ключевого поля |
|||
|
#18+
Таблица может иметь несколько ограничений уникальности. Одно из них в Вашем случае - уникальность пары начальный_узел_ИД и узел_направления_ИД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
08.06.2006, 13:39
|
|||
|---|---|---|---|
|
|||
Организация ключевого поля |
|||
|
#18+
<<уникальность пары начальный_узел_ИД и узел_направления_ИД.>> Согласен для для таблицы с узлами сочетание начальный_узел_ИД и узел_направления_ИД будет однозначно указывать на нужную запись. А вот для таблицы с общими данными нужно иметь ключ кот. уникален для двух пар и как-нибудь автоматом его формировать, т. е. начальный_узел_ИД-------узел_направления_ИД----------код_пролета 1------------------------------2------------------------------А 2------------------------------1------------------------------А 2------------------------------3------------------------------Б 3------------------------------2------------------------------Б ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
08.06.2006, 18:29
|
|||
|---|---|---|---|
Организация ключевого поля |
|||
|
#18+
Не совсем понятно, для чего две записи про пролет. Чем плохо ПРОЛЕТ (ИД, УЗЕЛ1_ИД, УЗЕЛ2_ИД, Информация_направления_1_2, Информация_направления_2_1) КЛЮЧ (ИД) КЛЮЧ (УЗЕЛ1_ИД, УЗЕЛ2_ИД). Если все же нужно ПРОЛЕТ (ИД, Общая информация) КЛЮЧ (ИД). НАПРАВЛЕНИЕ (Пролет_ИД, Начальный_узел_ИД, Узел_направления_ИД, Информация_направления) КЛЮЧ (Пролет_ИД, Начальный_узел_ИД) КЛЮЧ (Пролет_ИД, Узел_направления_ИД) КЛЮЧ (Начальный_узел_ИД, Узел_направления_ИД) То можно еще задать требование парности: ВНЕШНИЙ КЛЮЧ (Пролет_ИД, Начальный_узел_ИД) ССЫЛАЕТСЯ НА НАПРАВЛЕНИЕ (Пролет_ИД, Узел_направления_ИД) ВНЕШНИЙ КЛЮЧ (Пролет_ИД, Узел_направления_ИД ) ССЫЛАЕТСЯ НА НАПРАВЛЕНИЕ (Пролет_ИД, Начальный_узел_ИД) Но тогда добавление/изменение удаление парных запиcей нужно делать одним предложением. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
08.06.2006, 18:54
|
|||
|---|---|---|---|
Организация ключевого поля |
|||
|
#18+
И остается вопрос с ровно двумя записями для пролета - декларативная ссылочная целостность умеет считать лишь до одного, а нессылочным ограничениям вообще кроме собственной записи ничего видеть не положено.:( В пределах сессии решается триггером, а в многопользовательском режиме... проблема ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=32&mobile=1&tid=1545212]: |
0ms |
get settings: |
6ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
37ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
37ms |
get tp. blocked users: |
1ms |
| others: | 201ms |
| total: | 309ms |
| 0 / 0 |
