|
|
|
Зависимые сущности и идентифицирующие связи: ссылки основной таблицы на записи дочерней
|
|||
|---|---|---|---|
|
#18+
ChA, дружище, Вам даже Дейта читать рано, несмотря на то, что он пишет очень просто. Начните с логики. Любой. > без всяких пояснений Дорастете до пояснений - получите их. Пока просто читайте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2009, 09:31 |
|
||
|
Зависимые сущности и идентифицирующие связи: ссылки основной таблицы на записи дочерней
|
|||
|---|---|---|---|
|
#18+
Сахават Юсифовчеку хотся, щоб допустим в гриде был "Организация, телефон основной" Я с гридами на редактирование не работаю ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2009, 15:28 |
|
||
|
Зависимые сущности и идентифицирующие связи: ссылки основной таблицы на записи дочерней
|
|||
|---|---|---|---|
|
#18+
guest_20040621ChA, дружище, Вам даже Дейта читать рано, несмотря на то, что он пишет очень просто. Начните с логики. Любой.guest_20040621, дружище, если судить по дефектам Вашей, то читать вообще вредно. Хотя, надеюсь, что выборка непредставительная и просто имеет место индивидуальная непереносимость.guest_20040621Дорастете до пояснений - получите их. Пока просто читайте.Дружок, от Вас никто никогда ничего не получит. Кроме раздутых щёк и непомерного самомнения. Боюсь, это неизлечимо. P.S. Благодаря таким вот "проектировщикам" базы и "засраны" суррогатными ключами при одновременном дублировании фактической информации и нарушении ссылочной целостности. Тоже наверное читали Галилея с Аристотелем, а потом много думали. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2009, 15:47 |
|
||
|
Зависимые сущности и идентифицирующие связи: ссылки основной таблицы на записи дочерней
|
|||
|---|---|---|---|
|
#18+
ChA, меняйте работу. Мало того, что Вы напрасно получаете деньги за проектирование баз данных, Вы просто глупый человек. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2009, 16:41 |
|
||
|
Зависимые сущности и идентифицирующие связи: ссылки основной таблицы на записи дочерней
|
|||
|---|---|---|---|
|
#18+
guest_20040621ChA, меняйте работу. Мало того, что Вы напрасно получаете деньги за проектирование баз данных, Вы просто глупый человек.Дружище, не плюйтесь в экран. Посмотритесь в зеркало и Ваше душевное равновесие будет восстановлено. Кстати, неплохо также познакомиться с Гегелем и Кантом, они тоже сильно помогают в проектировании БД, надо только их внимательно слушать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2009, 16:52 |
|
||
|
Зависимые сущности и идентифицирующие связи: ссылки основной таблицы на записи дочерней
|
|||
|---|---|---|---|
|
#18+
Друзья, не ссорьтесь! :) guest_20040621 , если я правильно вас понял - вы против того, чтобы в состав первичного ключа зависимой сущности входил первичный ключ родительской сущности ? (считаем, что все ключи - суррогатные (int, автоинкремент)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2009, 16:57 |
|
||
|
Зависимые сущности и идентифицирующие связи: ссылки основной таблицы на записи дочерней
|
|||
|---|---|---|---|
|
#18+
Сахават Юсифов чеку хотся, щоб допустим в гриде был "Организация, телефон основной" и при этом хотелось бы этот телефон из лукапа менять по желанию из "Телефоны организации" и при этом НЕ вводить дополнительный признак "основности" в "Телефоны организации" и при этом обойтис только ДДЛ. Сахават Юсифов , не обязательно грид, но в целом все правильно :) Или вы считаете такой подход к интерфейсу и/или структуре БД неправильным? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2009, 16:59 |
|
||
|
Зависимые сущности и идентифицирующие связи: ссылки основной таблицы на записи дочерней
|
|||
|---|---|---|---|
|
#18+
ИМХО, примарный ключ должен быть: 1. суррогатным 2. атомарным 2.1 возможное исключение распределенные БД, тогда составной: ключ базы и ключ В базе С уважением, Naf ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2009, 17:18 |
|
||
|
Зависимые сущности и идентифицирующие связи: ссылки основной таблицы на записи дочерней
|
|||
|---|---|---|---|
|
#18+
ChA, с равновесием у меня все в порядке, спасибо. Я испытываю сожаление, что напрасно потратил время на контакт с Вами: тупость - худшее из человеческих качеств. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2009, 17:49 |
|
||
|
Зависимые сущности и идентифицирующие связи: ссылки основной таблицы на записи дочерней
|
|||
|---|---|---|---|
|
#18+
_мод, Ivan Shkuropadsky, я воще то сделал акцент ДОПУСТИМ в гриде :) Да нормальная практика, "основное место работы", "старшая жена", "любимый ресторан" ... вся жисть из этого интерфеса и состоит. а вот РСУД не может адекватно все это отразить, там кроме ссылочной целостности (и то до первого селекта без ключа :):):), т.е офигенные возможности трансформации без учета семантики) нифига нету :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2009, 19:03 |
|
||
|
Зависимые сущности и идентифицирующие связи: ссылки основной таблицы на записи дочерней
|
|||
|---|---|---|---|
|
#18+
guest_20040621Я испытываю сожаление, что напрасно потратил время на контакт с Вами: тупость - худшее из человеческих качеств.Поздравляю, дружок, осознание своих недостатков - верный путь к выздоровлению. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2009, 19:33 |
|
||
|
Зависимые сущности и идентифицирующие связи: ссылки основной таблицы на записи дочерней
|
|||
|---|---|---|---|
|
#18+
NafИМХО, примарный ключ должен быть: 1. суррогатным 2. атомарным Можете обосновать необходимость суррогатного атомарного основного ключа в таблицах, реализующих, например, связи сущностей M:N ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2009, 19:38 |
|
||
|
Зависимые сущности и идентифицирующие связи: ссылки основной таблицы на записи дочерней
|
|||
|---|---|---|---|
|
#18+
Naf пишет: > ИМХО, примарный ключ должен быть: > 1. суррогатным > 2. атомарным > 2.1 возможное исключение распределенные БД, тогда составной: ключ базы и > ключ В базе Это всё верно, но для независимой сущности. Есть сущности исключительно зависимые. Там лишний суррогатный ключ -- это зло. А составной -- нормальное и правильное решение. Пример: Счёт-фактура -- независимая сущность с суррогатным ключём. Позиция счёта-фактуры -- зависимая сущность с составным ключём: идентификатор счёта-фактуры и номер (идентификатор) позиции счёта-фактуры. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2009, 20:58 |
|
||
|
Зависимые сущности и идентифицирующие связи: ссылки основной таблицы на записи дочерней
|
|||
|---|---|---|---|
|
#18+
ChA пишет: > Дружище, не плюйтесь в экран. ChA, не надоело ещё на троллей время и нервы тратить ? Ты не пиши ничего -- он и заткнётся. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2009, 21:11 |
|
||
|
Зависимые сущности и идентифицирующие связи: ссылки основной таблицы на записи дочерней
|
|||
|---|---|---|---|
|
#18+
MasterZiv ChA, не надоело ещё на троллей время и нервы тратить ? Ты не пиши ничего -- он и заткнётся. Да, нет, даже забавно стало :) Впрочем, ты прав, общаясь с троллем сам понемногу в него превращаешься, надо завязывать. P.S. Просто "задолбало" наблюдать, как любой топик с участием анонима превращается в топик самолюбования. Вот все вокруг такие бараны, и один он, весь из себя такой красивый, прямо в центре стада ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2009, 21:21 |
|
||
|
Зависимые сущности и идентифицирующие связи: ссылки основной таблицы на записи дочерней
|
|||
|---|---|---|---|
|
#18+
ChANafИМХО, примарный ключ должен быть: 1. суррогатным 2. атомарным Можете обосновать необходимость суррогатного атомарного основного ключа в таблицах, реализующих, например, связи сущностей M:N ? Пример: 2 сущности - Организации, ФизЛица множественная ассоциация между ними: Работник(Организация,Физлицо) - многие-ко-многим Организация может содержать множество работников, Физлицо может быть работником нескольких организаций: в разный период действия, а также быть внешним или внутренним совместителем. Сущности начислений и удержаний работников имеют ссылки именно на ассоциативную сущность Работник: именно от параметров ассоциации (оклад, срок выслуги) зависят расчеты по ним. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2009, 10:02 |
|
||
|
Зависимые сущности и идентифицирующие связи: ссылки основной таблицы на записи дочерней
|
|||
|---|---|---|---|
|
#18+
MasterZiv Naf пишет: > ИМХО, примарный ключ должен быть: > 1. суррогатным > 2. атомарным > 2.1 возможное исключение распределенные БД, тогда составной: ключ базы и > ключ В базе Это всё верно, но для независимой сущности. Есть сущности исключительно зависимые. Там лишний суррогатный ключ -- это зло. А составной -- нормальное и правильное решение. Пример: Счёт-фактура -- независимая сущность с суррогатным ключём. Позиция счёта-фактуры -- зависимая сущность с составным ключём: идентификатор счёта-фактуры и номер (идентификатор) позиции счёта-фактуры. Почему не сделать атомарный первичный ключ и внешний ключ на документ-владелец? Если понадобится отразить в агрегированной таблице по какой строке начислен НДС, то достаточно будет добавить атомарный внешний ключ на таблицу позиций. Если же позиция изменится, то в вашем случае придется ее менять и во внешней таблице ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2009, 10:07 |
|
||
|
Зависимые сущности и идентифицирующие связи: ссылки основной таблицы на записи дочерней
|
|||
|---|---|---|---|
|
#18+
Спасибо всем за высказанные мнения! :) Я чувствую, моя проблема сейчас в том, что не могу выработать самостоятельно принципы, по которым сущности следует рассматривать как зависимые... "Независимая сущность не нуждается в информации из другой сущности для идентификации уникального экземпляра." (http://www.interface.ru/ca/comp.htm) Т.е. если не отвлекаться на суррогатность ключей, то исходить нужно именно из возможностей самоидентификации. Поэтому, например: - Банковский счет (организации) - это независимая сущность (от организации). - Сотрудник (организации) - это независимая сущность (идентифицируется как конкретный человек). - Подразделение (организации) - это зависимая сущность. - Адрес (один из нескольких адресов организации) - это независимая сущность. А вот, например, - Контракт (с одним и только одним клиентом) - это зависимая (от клиента) сущность? Ведь у контракта есть свой номер и дата. Следовательно ссылка на клиента для идентификации не требуется. Т.е. контракт - независимая сущность. И еще: Страна, Регион, Город. Регион - зависимая от Страны сущность, поскольку без страны не идентифицируется. Город - зависимая от Страны сущность, НО! независимая от Региона, поскольку есть страны без регионов и город идентифицируется только с учетом страны. Я нигде не ошибаюсь в рассуждениях? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2009, 11:18 |
|
||
|
Зависимые сущности и идентифицирующие связи: ссылки основной таблицы на записи дочерней
|
|||
|---|---|---|---|
|
#18+
Сахават ЮсифовДа нормальная практика, "основное место работы", "старшая жена", "любимый ресторан" ... вся жисть из этого интерфеса и состоит( Есть сущность Человек, у него есть атрибут Список мест работы, один из элементов этого списка имеет атрибут Основное, а остальные - По совместительству. И только так. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2009, 14:36 |
|
||
|
Зависимые сущности и идентифицирующие связи: ссылки основной таблицы на записи дочерней
|
|||
|---|---|---|---|
|
#18+
ChAМожете обосновать необходимость суррогатного атомарного основного ключа в таблицах, реализующих, например, связи сущностей M:N ? Элементарно: аудит ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2009, 14:37 |
|
||
|
Зависимые сущности и идентифицирующие связи: ссылки основной таблицы на записи дочерней
|
|||
|---|---|---|---|
|
#18+
_модСахават ЮсифовДа нормальная практика, "основное место работы", "старшая жена", "любимый ресторан" ... вся жисть из этого интерфеса и состоит( Есть сущность Человек, у него есть атрибут Список мест работы, один из элементов этого списка имеет атрибут Основное, а остальные - По совместительству. И только так.у человека нет основного места работы, а есть основное место работы на такую-то дату ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2009, 14:42 |
|
||
|
Зависимые сущности и идентифицирующие связи: ссылки основной таблицы на записи дочерней
|
|||
|---|---|---|---|
|
#18+
Nafу человека нет основного места работы, а есть основное место работы на такую-то дату Все значения атрибутов сущности действительны на дату ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2009, 14:46 |
|
||
|
Зависимые сущности и идентифицирующие связи: ссылки основной таблицы на записи дочерней
|
|||
|---|---|---|---|
|
#18+
Ivan Shkuropadsky, Проблема в том, что все сильно зависит от задачи, области применения. И у всех участников свое видение, собственно спор отчасти из-за этого, мне кажется. Например, сущность Адрес является возможно независимой в БД регистрации граждан по месту проживания. Однако, в бухгалтерской программе адрес контрагента вообще может не являться сущностью, а быть просто строковым реквизитом или сильно зависимой от контрагента сущностью - контакт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2009, 14:46 |
|
||
|
Зависимые сущности и идентифицирующие связи: ссылки основной таблицы на записи дочерней
|
|||
|---|---|---|---|
|
#18+
_модNafу человека нет основного места работы, а есть основное место работы на такую-то дату Все значения атрибутов сущности действительны на датуопять же, на какую. вам возможно достаточно на текущую, а в другой задаче нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2009, 14:47 |
|
||
|
Зависимые сущности и идентифицирующие связи: ссылки основной таблицы на записи дочерней
|
|||
|---|---|---|---|
|
#18+
Ivan Shkuropadsky Я нигде не ошибаюсь в рассуждениях? Все сущности независимы по определению. Просто между ними м.б. ссылки. Например: есть Организации и Подразделения, Подразделения ссылаются на Организации. Но можно получить список всех подразделений независимо от Организации по какому-либо признаку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2009, 14:52 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=36212693&tid=1543054]: |
0ms |
get settings: |
7ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
166ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
40ms |
get tp. blocked users: |
1ms |
| others: | 229ms |
| total: | 467ms |

| 0 / 0 |
