Здравствуйте, VladiCh, Вы писали:


VC>Если же PK будет только groupId, то возможна ситуация когда у группы назначен один регион а у пользователя другой — тоже (не)нормально.
Начните с запросов. "правильность" схемы данных зависит в первую очередь от запросов, которые вы к этой схеме будете делать.

Например если вы делаете запрос такого вида:

srlrct u.userId, u.groupId, g.regionId, COALESCE(g.region, u.region) as region
from user u
left join gorup g on u.groupId = g.groupId

то неоднозначности поля region нет

Но если вы получаете и обрабатываете user отдельно от его group, то могут быть проблемы. То я бы предложил констрейнтом задать правило, что нельзя одновременно заполнить region и groupId в user

Здравствуйте, VladiCh, Вы писали:

VC>…возможна ситуация когда у группы назначен один регион а у пользователя другой — тоже (не)нормально.

В таблице пользователей, если ваша СУБД это позволяет, можно завести CHECK CONSTRAINT, который даст гарантию, что или группа или регион (но обязательно что-то одно) будет установлено в некоторое значение.

Как с теоретической точки зрения правильно нормализовать очень простую схему из 2х отношений:

1. user
--------
userId
groupId
region

2. group
--------
groupId
region

Пользователь всегда принадлежит к какому-то региону но не всегда к группе.
Когда он принадлежит к группе, его регион совпадает с регионом группы (берется из него)
То есть по идее groupId + region должны быть PK в group,
Но в таком случае когда пользователь не принадлежит к группе, то у него теряется region.
или столбцов region должно быть 2, что также не является нормализованным вариантом.
Если же PK будет только groupId, то возможна ситуация когда у группы назначен один регион а у пользователя другой — тоже (не)нормально.

Здравствуйте, VladiCh, Вы писали:

VC>Как с теоретической точки зрения правильно нормализовать очень простую схему из 2х отношений:

VC>1. user
VC>--------
VC>userId
VC>groupId
VC>region

VC>2. group
VC>--------
VC>groupId
VC>region

VC>Пользователь всегда принадлежит к какому-то региону но не всегда к группе.
VC>Когда он принадлежит к группе, его регион совпадает с регионом группы (берется из него)
VC>То есть по идее groupId + region должны быть PK в group,
VC>Но в таком случае когда пользователь не принадлежит к группе, то у него теряется region.
VC>или столбцов region должно быть 2, что также не является нормализованным вариантом.
VC>Если же PK будет только groupId, то возможна ситуация когда у группы назначен один регион а у пользователя другой — тоже (не)нормально.

Так на пальцах: таблица Регион и таблица Группа имеют связь 1 к 1 к базовой таблице(назвать можно по разному), эта таблица имеет связь 1 ко многим с таблицей Пользователь, таблица Регион имеет связь 1 ко многим с таблицей Группа. Получается, что пользователь может быть ассоциирован либо с регионом, либо с группой у которой уже есть регион.

Здравствуйте, Qulac, Вы писали:

Q>Здравствуйте, VladiCh, Вы писали:

VC>>Как с теоретической точки зрения правильно нормализовать очень простую схему из 2х отношений:

VC>>1. user
VC>>--------
VC>>userId
VC>>groupId
VC>>region

VC>>2. group
VC>>--------
VC>>groupId
VC>>region

VC>>Пользователь всегда принадлежит к какому-то региону но не всегда к группе.
VC>>Когда он принадлежит к группе, его регион совпадает с регионом группы (берется из него)
VC>>То есть по идее groupId + region должны быть PK в group,
VC>>Но в таком случае когда пользователь не принадлежит к группе, то у него теряется region.
VC>>или столбцов region должно быть 2, что также не является нормализованным вариантом.
VC>>Если же PK будет только groupId, то возможна ситуация когда у группы назначен один регион а у пользователя другой — тоже (не)нормально.

Q>Так на пальцах: таблица Регион и таблица Группа имеют связь 1 к 1 к базовой таблице(назвать можно по разному), эта таблица имеет связь 1 ко многим с таблицей Пользователь, таблица Регион имеет связь 1 ко многим с таблицей Группа. Получается, что пользователь может быть ассоциирован либо с регионом, либо с группой у которой уже есть регион.

много лишних сущностей (базовая таблица, таблица регионов), отношения между ними.
столбец region однозначно идентифицирует регион, ему не нужна таблица (она будет из одного столбца)
на самом деле я как-то упустил один несколько тонкий момент...
что если в композитной ссылке хотя бы один столбец is null, то она вся считается пустой и не проверяется по FK.
так что вопрос снят .

Здравствуйте, VladiCh, Вы писали:

VC>Если же PK будет только groupId, то возможна ситуация когда у группы назначен один регион а у пользователя другой — тоже (не)нормально.
БД не может обеспечить все констрейны, часть все равно будет в коде приложения.
В данном конкретном случае можно делать группы "Без группы в регионе N" по одной в каждом регионе.