|
Действия ...
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
30.07.2008, 11:51
|
|||
|---|---|---|---|
Несколько связей между двумя таблицами |
|||
|
#18+
Разбираю чужую структуру БД. Между двумя очень объемными таблицами существует порядка 4 связей (3 один к многим и 4-ая многие к многим), наверное для различных запросов. Таблицы нормализованы. Ситуация нормальная?? зы в первый раз сталкиваюсь с такой объемной и сложной БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.07.2008, 12:02
|
|||
|---|---|---|---|
Несколько связей между двумя таблицами |
|||
|
#18+
vitaliy14Разбираю чужую структуру БД. Между двумя очень объемными таблицами существует порядка 4 связей (3 один к многим и 4-ая многие к многим), наверное для различных запросов. Таблицы нормализованы. Ситуация нормальная?? зы в первый раз сталкиваюсь с такой объемной и сложной БД. Нормально, бывает и хуже. Какой SQL-сервер? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.07.2008, 12:09
|
|||
|---|---|---|---|
Несколько связей между двумя таблицами |
|||
|
#18+
Senya_L vitaliy14Разбираю чужую структуру БД. Между двумя очень объемными таблицами существует порядка 4 связей (3 один к многим и 4-ая многие к многим), наверное для различных запросов. Таблицы нормализованы. Ситуация нормальная?? зы в первый раз сталкиваюсь с такой объемной и сложной БД. Нормально, бывает и хуже. Какой SQL-сервер? MSSQL 2000 по логике тоже, так кажется. Не сложные запросы зато получаются. Прсто громоздко на схеме выглядит!? ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.07.2008, 12:31
|
|||
|---|---|---|---|
Несколько связей между двумя таблицами |
|||
|
#18+
vitaliy14 Senya_L vitaliy14Разбираю чужую структуру БД. Между двумя очень объемными таблицами существует порядка 4 связей (3 один к многим и 4-ая многие к многим), наверное для различных запросов. Таблицы нормализованы. Ситуация нормальная?? зы в первый раз сталкиваюсь с такой объемной и сложной БД. Нормально, бывает и хуже. Какой SQL-сервер? MSSQL 2000 по логике тоже, так кажется. Не сложные запросы зато получаются. Прсто громоздко на схеме выглядит!? ) Схемы нужны для лучшего понимания структуры БД, а не для того, чтобы они красиво выглядели. Если схема не очень наглядно, к ней прикладывается пояснение. Не заморачивайся этими CASE-средствами проектирования. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.07.2008, 12:35
|
|||
|---|---|---|---|
|
|||
Несколько связей между двумя таблицами |
|||
|
#18+
vitaliy14по логике тоже, так кажется. Не сложные запросы зато получаются. Прсто громоздко на схеме выглядит!? )Запросы не обязательно зависят от связей. которые отображены на схеме. Если в запросе джоин не будет указан явно, никакая связь из схемы не поможет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.07.2008, 12:51
|
|||
|---|---|---|---|
Несколько связей между двумя таблицами |
|||
|
#18+
Еще один вопрос - Есть таблица "работа" и "подразделение заказчика". У каждой работы может быть несколько подразделений, но главное только одно ! (для этого есть поле IS_MAIN (yes/no)). Триггер нужно писать на update и insert? (Constraint не напишешь) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.07.2008, 12:55
|
|||
|---|---|---|---|
|
|||
Несколько связей между двумя таблицами |
|||
|
#18+
vitaliy14но главное только одно ! (для этого есть поле IS_MAIN (yes/no)) Видимо, речь про дополнительную табличку и связь M:N? Так вот, в случае такой таблички есть методы попроще, без IS_MAIN-ов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.07.2008, 13:10
|
|||
|---|---|---|---|
Несколько связей между двумя таблицами |
|||
|
#18+
Сергей Васкецов vitaliy14но главное только одно ! (для этого есть поле IS_MAIN (yes/no)) Видимо, речь про дополнительную табличку и связь M:N? Так вот, в случае такой таблички есть методы попроще, без IS_MAIN-ов. Да 3-я таблица "многие к многим". Какие методы? Пример бы мне? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.07.2008, 13:30
|
|||
|---|---|---|---|
|
|||
Несколько связей между двумя таблицами |
|||
|
#18+
vitaliy14Пример бы мне? Делаете поле типа npp (номер по порядку). При выводе на печать сортируете по нему (все равно определенность нужна, а таким способом легко вручную управлять порядком записей). Главное подразделение - то, которое первое (с минимальным npp). Никаких ненужных триггеров. Если нужна гарантированная сортировка даже при совпадении значений npp, добавляете в перечень полей сортировки идентификатор. Надеюсь, уникальный индекс уже есть в этой таблице по паре полей "работа" и "подразделение"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.07.2008, 13:48
|
|||
|---|---|---|---|
Несколько связей между двумя таблицами |
|||
|
#18+
Нет еще ничего таблицы пустые! Т.е. по пунктам Таблица Работа-ПЗ (подразделение заказчика) ---------------------------------------------- ID_JOB_Customer ID_JOB ID_Customer NPP 1. Нужно сделать unique индекс по полям ID_JOB - ID_Customer - NPP? 2. И считать NPP c 1 для главного? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.07.2008, 13:56
|
|||
|---|---|---|---|
|
|||
Несколько связей между двумя таблицами |
|||
|
#18+
vitaliy14Нужно сделать unique индекс по полям ID_JOB - ID_Customer - NPP? Не-а, только по паре полей ID_JOB и ID_Customer. vitaliy14И считать NPP c 1 для главного? Да можно и с нуля. Не принципиально. Сортировка может быть типа order by sign(npp) desc,npp,ID_Customer или order by npp,ID_Customer. В первом случае все новые строки с нулевым значением npp будут "падать в конец". ID_Customer можно заменить на ID_JOB_Customer. Записей таких по сути немного будет, так что что бы Вы ни выдумали (в части сортировки), для сервера это будет не напряжно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.07.2008, 14:13
|
|||
|---|---|---|---|
Несколько связей между двумя таблицами |
|||
|
#18+
Не работает или я вас не понял! получается id | id_customer| id_job | npp --------------------------- 1 | 1 | 1 | 1 2 | 2 | 1 | 1 Два ПЗ главных? Мне же нужно - для каждой работы из нескольких подразделений ее выполнявших одно было главным! Индекс по id_job и npp нужно строить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.07.2008, 14:15
|
|||
|---|---|---|---|
Несколько связей между двумя таблицами |
|||
|
#18+
id | id_customer| id_job | npp --------------------------- 1 | 1 | 1 | 1 <-----| 2 | 2 | 1 | 1 <-------- Два ПЗ главных? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.07.2008, 14:15
|
|||
|---|---|---|---|
|
|||
Несколько связей между двумя таблицами |
|||
|
#18+
vitaliy14Два ПЗ главных? Главное - первое - всегда одно. Впрочем, можете сделать дополнительный уникальный индекс по ID_JOB и npp, если уж так хочется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.07.2008, 14:22
|
|||
|---|---|---|---|
|
|||
Несколько связей между двумя таблицами |
|||
|
#18+
Нужно в таблице Работ хранить ссылка на главное подразделение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.07.2008, 14:23
|
|||
|---|---|---|---|
Несколько связей между двумя таблицами |
|||
|
#18+
Сергей Васкецов vitaliy14Два ПЗ главных? Главное - первое - всегда одно. Впрочем, можете сделать дополнительный уникальный индекс по ID_JOB и npp, если уж так хочется. Подождите запутался unique индекс только по полям ID_JOB - NPP - чтобы не было двух главных подразделений н а одну работу? и unique индекс по полям ID_JOB - ID_Customer, чтобы не было абсурда? Спасибо Вам большое :) зы это не единственная таблица с такими условиями, подобное нужно еще в нескольких местах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.07.2008, 14:27
|
|||
|---|---|---|---|
Несколько связей между двумя таблицами |
|||
|
#18+
Все очень простоНужно в таблице Работ хранить ссылка на главное подразделение. В смысле если не NULL, то главное! Помойму Сергей Васкецов предложил достаточно элегантное решение ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.07.2008, 14:31
|
|||
|---|---|---|---|
|
|||
Несколько связей между двумя таблицами |
|||
|
#18+
Нет Работа должна сылать на главное подразделение. В таблице справочника Работ должно быть поле в котором хранится ссылка на таблицу справчоника подразделений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.07.2008, 14:32
|
|||
|---|---|---|---|
|
|||
Несколько связей между двумя таблицами |
|||
|
#18+
Т.е. по сути еще одна связь "Главное подразделение" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.07.2008, 14:33
|
|||
|---|---|---|---|
|
|||
Несколько связей между двумя таблицами |
|||
|
#18+
А хранить это в как признак в другой связи ИМХО неверно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.07.2008, 14:44
|
|||
|---|---|---|---|
|
|||
Несколько связей между двумя таблицами |
|||
|
#18+
vitaliy14unique индекс только по полям ID_JOB - NPP - чтобы не было двух главных подразделений н а одну работу? 1. Можно сделать уникальный индекс. Тогда при редактировании необходимо будет разруливать ситуацию (на уровне интерфейса, видимо), когда потребуется поменять местами два подразделения. 2. Можно не делать уникальный индекс, а обойтись сортировкой. Для получения главного подразделения использовать select top 1 ...., тогда ошибки нарушения индекса не будет (так как не будет индекса). 3. Можно сделать ссылку на главное подразделение как отдельный атрибут работы. В таком случае потребуется в зависимости от постановки задачи либо проверять, что ссылки на главное подразделение нет в перечне подразделений, либо наоборот, требовать в перечне подразделений ссылку на главное. То есть, в зависимости от логики, список подразделений будет либо списком всех используемых подразделений, либо списком всех вспомогательных подразделений. С моей точки зрения, решение идиотское как по постановке, так и по трудозатратам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.07.2008, 14:45
|
|||
|---|---|---|---|
|
|||
Несколько связей между двумя таблицами |
|||
|
#18+
Все очень простоНет Работа должна сылать на главное подразделение Прокомментировал сообщением выше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.07.2008, 14:53
|
|||
|---|---|---|---|
|
|||
Несколько связей между двумя таблицами |
|||
|
#18+
А если хранить ссылку на элемнт перечня работ ? Проверять ничего не надо это БД проверяет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.07.2008, 15:04
|
|||
|---|---|---|---|
|
|||
Несколько связей между двумя таблицами |
|||
|
#18+
Сергей Васкецов vitaliy14unique индекс только по полям ID_JOB - NPP - чтобы не было двух главных подразделений н а одну работу? 1. Можно сделать уникальный индекс. Тогда при редактировании необходимо будет разруливать ситуацию (на уровне интерфейса, видимо), когда потребуется поменять местами два подразделения. 2. Можно не делать уникальный индекс, а обойтись сортировкой. Для получения главного подразделения использовать select top 1 ...., тогда ошибки нарушения индекса не будет (так как не будет индекса). Предложенный тобой вариант технически неграмотный и трудно(много кода, накладно для базы) реализуемый. Насколько я понял мы говорим о многопользовательском домтупе к БД. Если 1-й твой вариант еще хоть как-то будет что-то гарантировать, то 2-й вообще ничего не будет гарантировать, т.е. будем иметь несоклько главных подразделений. ИМХО решение попахивает ламеризмом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.07.2008, 15:40
|
|||
|---|---|---|---|
Несколько связей между двумя таблицами |
|||
|
#18+
автор Можно не делать уникальный индекс, а обойтись сортировкой. Для получения главного подразделения использовать select top 1 ...., тогда ошибки нарушения индекса не будет (так как не будет индекса). Действительно, 1 вариант хороший, но гемморой с редактированием. 2 вариант - проблем с редактированием нет, но прийдется на клиенте проверять,чтобы пользователи два ПЗ не сделали главными. Тогда теряется вообще какой-то смысл в ограничениях! Наверное 3. Хоть и будет избыточность, но проблем в первых 2 вариантах не будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=32&tablet=1&tid=1543731]: |
0ms |
get settings: |
8ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
177ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
83ms |
get tp. blocked users: |
2ms |
| others: | 197ms |
| total: | 504ms |
| 0 / 0 |
