| Результаты опроса: Какой метод связи нескольких таблиц Вы предпочитаете? | |||
| Тип связи задается енумом. Значение связи в одном поле |
   
|
8 | 53.33% |
| Связь задается в отдельных полях. Тип связи определяется заполненностью полей |
  
|
3 | 20.00% |
| Мне все равно. Как сделают постановку задачи так и будет |
  
|
4 | 26.67% |
| Голосовавшие: 15. Вы ещё не голосовали в этом опросе | |||
|
|
Опции темы |
13.08.2018, 13:53
|
#15 |
|
Участник
|
Цитата:
Сообщение от Ivanhoe
Уже второй раз этот аргумент. Если мы строим связи через эти поля, очевидно, не могут быть они заполнены одновременно.
Факт заполнения обеих полей на собственно СВЯЗИ не влияет НИКАК. От слова "совсем" А влияет это не на связи, а на интерпретацию (вычисление) некоего реквизита. Т.е. на основании факта заполнения тех или иных полей Вы формируете некое "вычисляемое" поле, на основании которого и строите дальнейшую логику работы Так почему вместо "вычислений" не указать это значение явно? Через дополнительный Base Enum? Возвращаемся к примеру Есть Base Enum со значениями: All/Group/Item Цель и смысл существования этого поля? Разве для создания Relation? Вовсе нет! Его цель и смысл - это некий switch в программном коде. Некое "ветвление кода" А Relation для чего? Для автоматического перехода к нужной записи таблицы. Ну, и как повлияет на КОД (тот самый switch) факт заполнения обеих полей? Это влияние возможно в том и только в том случае, если у Вас нет Base Enum и Вы вынуждены каким-то образом "вычислять" по какой ветке кода пойдет обработка. А вычисление - это всегда некоторая неопределенность
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
|
Древовидный вид