powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Связь между двумя таблицами. Допустим ли такой вариант?
16 сообщений из 16, страница 1 из 1
Связь между двумя таблицами. Допустим ли такой вариант?
    #37790327
Gamber
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Проектриую БД для приложения.
Возник вопрос по взаимоотношениям между двумя таблицами.

Таблица "Operators" - хранит сведения о лицах вносящих изменения в базу.
Поле "name_operator" - логин пользователя в системе.

Таблица "Clients" - хранит информацию о всех сотрудниках организации, в том числе и об операторах.

Соответственно подробные данные об операторе (ФИО, телефон и пр.) тянется из "Clients". Связь 1-1.
В самой же таблице "Clients" отмечается какой оператор вносил/изменял данные в таблицу. Связь 1-*.

Допустимо ли делать такую связь - друг на друга?
Подскажите пожалуйста...
...
Рейтинг: 0 / 0
Связь между двумя таблицами. Допустим ли такой вариант?
    #37790648
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GamberВ самой же таблице "Clients" отмечается какой оператор вносил/изменял данные в таблицу.
Связь 1-*.

А ты уверен, что из таблицы операторов никогда не будет удалений?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Связь между двумя таблицами. Допустим ли такой вариант?
    #37790819
Gamber
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dimitry Sibiryakov,

Для поля id_operator в таблице "Clients" допустимо значение null, в первоначальном состоянии данное поле будет пустым и будет заполняться, только при одиночном добавлении новых записей и при изменении уже добавленных...

По связи 1-* (id_operator.clients = id_operator.operators)
В параметрах внешнего ключа задано занулять id_operator в случае удаления оператора, что на практике вряд ли будет происходить... Динамика смены состава операторов предполагается очень низкой...

По связи 1-1 (id_client.operators = id_client.clients)
В параметрах внешнего ключа запрещено удалять пользователя из таблицы "Clients" если он находится в числе операторов...
...
Рейтинг: 0 / 0
Связь между двумя таблицами. Допустим ли такой вариант?
    #37790847
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GamberДопустимо ли делать такую связь - друг на друга?
А что мешает? Всевозможные циклы в связях сущностей - следствие природы этих данных.

В некоторых случаях циклы приводят к техническим проблемам, которые приходится решать по месту.

Другой вопрос, что в данном случае непонятно предназначение сущности operators. Что в ней такого, что выделяет её из сущности clients (которая выглядит не очень удачно названной, если сравнивать с описанием).
...
Рейтинг: 0 / 0
Связь между двумя таблицами. Допустим ли такой вариант?
    #37791033
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GamberВ параметрах внешнего ключа задано занулять id_operator в случае удаления оператора

Прэлестно... Оператор уволился и уже никто никогда не узнает что именно он натворил в базе.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Связь между двумя таблицами. Допустим ли такой вариант?
    #37791183
Gamber
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
softwarerДругой вопрос, что в данном случае непонятно предназначение сущности operators. Что в ней такого, что выделяет её из сущности clients (которая выглядит не очень удачно названной, если сравнивать с описанием).
Суть создаваемого приложения - замена стандартного клиента системы удаленного управления рабочим столом...
Парк машин порядка ~3000 рабочих мест, саппорт около полусотни бойцов... Все в AD...

Таблица "Clients" (в схеме она несколько упрощенна, полей там поболее - около 10) - это слепок базы пользователей AD (сделан он будет однократно: несмотря на немалое количество пользователей интенсивность изменений записей в домене крайне низка)...

Саппорту никто в домен писать не разрешит, поэтому и делается своя автономаная таблица, плюс ко всему оперативность внесения изменений (сменился телефон, адрес, фамилия) будет значительно выше, чем у домена (ввиду особенностей конторы)...

Для работы с приложением необходимо будет подключиться к базе, у каждого оператора своя учетка на сервере СУБД, никаких внешних механизмов авторизации не предполагается...

Логин пользователя = "name_operator" в "Operators"...

На примере:
Допустим есть у нас оператор - сотрудник Василий Петрович Эникеев, в базе "Clients" он у нас с "id_client" = 2500...
Регистрируем его на сервере СУБД, даем ему логин - anykey...
Добавляем в таблицу "Operators" запись
Код: plaintext
1.
2.
id_operator | id_client | name_operator
      1          2500        anykey
Оператор авторизуется и заходит в систему...
По "name_operator" мы определяем, какой "id_operator" будем писать в "Clients"...

Возникает у него необходимость изменить запись одного из пользователей, он вносит изменения, в поле "id_operator" этой записи прописывается '1', в основном гриде приложения мы видим в измененной записи - ФИО оператора, который ее изменил (тянется из этой же таблицы Clients), при желании можем быстро запросить детальные данные оператора...

Dimitry SibiryakovПрэлестно... Оператор уволился и уже никто никогда не узнает что именно он натворил в базе.
Согласен, есть немного...
Таблица "Operators" будет носить сервисный характер, в приложении полностью светить ее не предполагается...
Удалять записи из "Clients" операторы тоже не смогут, будет просто ставиться пометка на удаление в соответствующем поле таблицы и данная запись будет скрываться из грида...

Как вариант, отказаться от удаления операторов полностью, просто сделать поле-флаг "Уволен" в таблице "Operators"...
Уволился оператор, ставим ему соответствующие отметки, "Удален" в "Clients" и "Уволен" в "Operators"...

Посмотреть подробную информацию о таком операторе можно будет без проблем, так же как и увидеть отметку что он "Уволен"...
Если оператор никаких действий по добавлению/изменению не предпринимал или все его пользователи тоже уволились, можно будет его удалить...
...
Рейтинг: 0 / 0
Связь между двумя таблицами. Допустим ли такой вариант?
    #37791302
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
> Таблица "Operators" - хранит сведения о лицах вносящих изменения в базу.
> Поле "name_operator" - логин пользователя в системе.
>
> Таблица "Clients" - хранит информацию о всех сотрудниках организации, в том
> числе и об операторах.
>
> Соответственно подробные данные об операторе (ФИО, телефон и пр.) тянется из
> "Clients". Связь 1-1.

Ну, во-первых, связь Operators-Clients 1:0..1, а не 1:1.

> В самой же таблице "Clients" отмечается какой оператор вносил/изменял данные в
> таблицу. Связь 1-*.
>
> Допустимо ли делать такую связь - друг на друга?

Да, только как минимум одно поле ссылок друг на друга должно быть NULL
(необязательная связь), иначе ты не сможешь добаить запись ни туда, ни туда.

Ну и удалять такие данные, если надо будет, то нужно будте по-хитрому --
сначала развязать связь, потом удалять.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Связь между двумя таблицами. Допустим ли такой вариант?
    #37791353
Gamber
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
MasterZivНу, во-первых, связь Operators-Clients 1:0..1, а не 1:1.

Да, Вы правы...
Все операторы являются пользователями (1-1).
Не каждый пользователь (
лишь избранный :)
) является оператором (1-0).
MasterZivДа, только как минимум одно поле ссылок друг на друга должно быть NULL
(необязательная связь), иначе ты не сможешь добаить запись ни туда, ни туда.

Ну если я правильно понял то так и есть...
Поле "id_operator" в таблице "Clients" необязательно...
Добавление новых операторов будет производиться вручную (добавили юзера на сервере, добавили оператора с name_operator = login и id_client = id_client.clients).
Я так понимаю проблем быть не должно?
MasterZivНу и удалять такие данные, если надо будет, то нужно будте по-хитрому --
сначала развязать связь, потом удалять.

Реально удалять операторов буду только в случае отсутствия нарушений целостности... В противном случае буду оставлять его в базе с пометкой "Уволен"...
Т.е. последовательность рисуется такая:
1. Есть уволившийся оператор;
2. Пробуем его удалить (если срабатывает Restrict, значит у него есть пользователи (клиенты));
3. Проверяем его клиентов;
3.1 Есть рабочие записи (не помеченные к удалению);
3.2 Все записи в "Clients" данного оператора помечены к удалению;
4. В случае 3.1 ставим отметку об увольнении оператора, в случае 3.2 удаляем клиентов оператора, удаляем оператора сначала из "Operators" затем из "Clients".
...
Рейтинг: 0 / 0
Связь между двумя таблицами. Допустим ли такой вариант?
    #37797672
Gamber
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Вот сделать то сделал...
А как посторить нужный SQL запрос никак не могу догнать...
Две таблицы:

Структура

1. Операторы
Код: sql
1.
2.
3.
id_operator (PK)
id_user (FK)
name_operator



2. Пользователи
Код: sql
1.
2.
3.
4.
id_user (PK)
name_user
email_user
id_operator (FK)



Данные:

1. Операторы
Код: sql
1.
2.
1 - 2 - ivanov
2 - 3 - sidorov



2. Пользователи
Код: sql
1.
2.
3.
1 - Петров Петр - petrov@mail.ru - 2
2 - Иванов Иван - ivanov@mail.ru - 3
3 - Сидоров Вася - sidorov@mail.ru - 2



На выходе нужно получить:

Код: sql
1.
2.
3.
1 - Петров Петр - petrov@mail.ru - Иванов Иван
2 - Иванов Иван - ivanov@mail.ru - Сидоров Вася 
3 - Сидоров Вася - sidorov@mail.ru - Иванов Иван



Получается только:

Код: sql
1.
2.
3.
1 - Петров Петр - petrov@mail.ru - ivanov
2 - Иванов Иван - ivanov@mail.ru - sidorov 
3 - Сидоров Вася - sidorov@mail.ru - ivanov



Пытаюсь делать вложенный SELECT
Код: sql
1.
2.
3.
4.
SELECT NAME_USER, NAME_OPERATOR, (SELECT NAME_USER FROM USERS, OPERATORS WHERE (OPERATORS.ID_USER = USERS.ID_USER))
FROM USERS, OPERATORS
WHERE (
USERS.ID_OPERATOR = OPERATORS.ID_OPERATOR)


получаю предсказуемое
Код: sql
1.
Subquery returns more than 1 row



Подскажите пожалуйста как сделать нужный запрос...
...
Рейтинг: 0 / 0
Связь между двумя таблицами. Допустим ли такой вариант?
    #37797710
Gamber
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Поправка
...
2. Пользователи
1 - Петров Петр - petrov@mail.ru - 1
2 - Иванов Иван - ivanov@mail.ru - 2
3 - Сидоров Вася - sidorov@mail.ru - 1
...
...
Рейтинг: 0 / 0
Связь между двумя таблицами. Допустим ли такой вариант?
    #37797727
Gamber
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Получилось...правда только через вьюшку...
Видимо по другому никак...
...
Рейтинг: 0 / 0
Связь между двумя таблицами. Допустим ли такой вариант?
    #37797729
serg99
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GamberПытаюсь делать вложенный SELECT
Код: sql
1.
2.
3.
4.
SELECT NAME_USER, NAME_OPERATOR, (SELECT NAME_USER FROM USERS, OPERATORS WHERE (OPERATORS.ID_USER = USERS.ID_USER))
FROM USERS, OPERATORS
WHERE (
USERS.ID_OPERATOR = OPERATORS.ID_OPERATOR)


получаю предсказуемое
Код: sql
1.
Subquery returns more than 1 row



Подскажите пожалуйста как сделать нужный запрос...

А SQL действительно не поддерживает случай когда подзапрос в разделе селекта возвращает больше одной строки?
...
Рейтинг: 0 / 0
Связь между двумя таблицами. Допустим ли такой вариант?
    #37798037
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
On 05/16/2012 08:35 PM, serg99 wrote:

> А SQL действительно не поддерживает случай когда подзапрос в разделе селекта
> возвращает больше одной строки?

Поддерживает. Только снаружи нужен соответствующий вводящий предикат,
допускающий эту множественность.

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Связь между двумя таблицами. Допустим ли такой вариант?
    #37798101
Gamber
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
MasterZivOn 05/16/2012 08:35 PM, serg99 wrote:

> А SQL действительно не поддерживает случай когда подзапрос в разделе селекта
> возвращает больше одной строки?

Поддерживает. Только снаружи нужен соответствующий вводящий предикат,
допускающий эту множественность.



Не подскажите как в данной ситуации это можно сделать?
...
Рейтинг: 0 / 0
Связь между двумя таблицами. Допустим ли такой вариант?
    #37798315
Xordal
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gamber,

а если объединить данные в одну таблицу? Или есть причины, мешающие этому? Например:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
declare @Users table
(
    id_user         int
    ,name_operator  varchar(128)
    ,name_user      varchar(128)
    ,email_user     varchar(128)
    ,parent_id      int
    ,is_operator    bit
)

insert into @Users
        (
        id_user       
        ,name_operator
        ,name_user    
        ,email_user   
        ,parent_id    
        ,is_operator
        )
select 1
        ,null
        ,'Петр Иванович'
        ,'petrov@mail.ru'
        ,2
        ,0
        
union
select 2
        ,'ivanov'
        ,'Иванов Иван'
        ,'ivanov@mail.ru'
        ,3
        ,1
        
union
select 3
        ,'sidorov'
        ,'Сидоров Вася'
        ,'sidorov@mail.ru'
        ,2
        ,1

select u.id_user
        ,u.name_user
        ,u.email_user
        ,pu.name_user
  from @Users u
  left join @Users pu
    on u.parent_id = pu.id_user
...
Рейтинг: 0 / 0
Связь между двумя таблицами. Допустим ли такой вариант?
    #37798516
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
> > А SQL действительно не поддерживает случай когда подзапрос в разделе селекта
> > возвращает больше одной строки?
>
> Поддерживает. Только снаружи нужен соответствующий вводящий предикат,
> допускающий эту множественность.

> Не подскажите как в данной ситуации это можно сделать?


В данном случае:

SELECT NAME_USER, NAME_OPERATOR, (SELECT NAME_USER FROM USERS, OPERATORS WHERE
OPERATORS.ID_USER = USERS.ID_USER)
FROM USERS, OPERATORS
WHERE USERS.ID_OPERATOR = OPERATORS.ID_OPERATOR

никак.

Потому что тут это не нужно, тут нужно ОДНО значение, которое будет помещено
в поле набора данных.

В данном случае надо переписать подзапрос
(SELECT NAME_USER FROM USERS, OPERATORS WHERE OPERATORS.ID_USER = USERS.ID_USER)

так, чтобы он возвращал только одну строку (и одно поле из неё, естественно).
В простейшем случае можно сделать что-то типа
(SELECT TOP 1 NAME_USER FROM USERS, OPERATORS WHERE OPERATORS.ID_USER =
USERS.ID_USER ORDER BY xxx )

Да, у тебя тут нет в подзапросе условия кореляции и видимо одна лишняя таблица.


p.s. нафига ты пишешь скобки в WHERE вокруг условий? Если всё же есть
какая-то причина, то почему ты их пишешь так мало ? Написал бы по 20 штук, что ли...
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
16 сообщений из 16, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Связь между двумя таблицами. Допустим ли такой вариант?
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]