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

Предметная область - высшее образование

Наверняка все это обсуждалось.
1) Связь один-к-одному. Все время считал, что почти всегда это зло, за редким исключением. Коллега думает по-другому.

Я прав? Какие доводы в пользу меня, а какие против?

Нашел обсуждение данной проблемы

Marat_LПожалуй да.
Иногда наверное надо. Например в случаях когда
1) Часть полей по логическому содержанию можно объединить в отдельную группу
2) Эта часть полей очень часто модифицируется
3) В таблице много других полей с индексами, которые обновляются значительно реже
4) А самое главное вычислительные издержки на 2) ощутимо превосходят издержки на объединение (хотя это трудно оценить)

Только так? у нас только пункт один выполняется.

2) Использование справочников допустимых значений. Имеет ли смысл для всех перечислений создавать отдельные таблицы с перечислением допустимых значений.

3) Не совсем имеет отношение к проектированию. Каждый пользователь подключается к базе под уникальным ИД. Необходимо разработать механизм отмены действий отдельного пользователя за укзанный период времени. Как решаются подобные задачи?

Заранее спасибо!
...
Рейтинг: 0 / 0
Подскажите пару моментов по проектированию!
    #35609497
GraDeaВсем привет!

3) Не совсем имеет отношение к проектированию. Каждый пользователь подключается к базе под уникальным ИД. Необходимо разработать механизм отмены действий отдельного пользователя за укзанный период времени. Как решаются подобные задачи?

Заранее спасибо!
Решается журналированием (регистрацией) проведенных пользователем изменений и проведением "обратных" преобразований...
Вот только привилегии у пользователей могут быть разные. И действия, выполняемые ими, тоже...
Например, возможна такая проблема:
один из суперпользователей ввел колонку в таблицу, другие (обычные) пользователи затем "навводили" в эту колонку значений... Затем, в один прекрасный день, среди прочих действий суперпользователя надо откатить добавление колонки в таблицу... Но тогда сделаем неактуальной "кучу" записей в журнале по вводу/изменению данных в указанную колонку...
...
Рейтинг: 0 / 0
Подскажите пару моментов по проектированию!
    #35609684
olzhas
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
1) cвязь 1 к 1 бывает очень полезна когда у вас "Широкие" таблицы. Тут все зависит от данных и типов запросов. Сразу и не скажешь.
2) Однозначно да, что бы поддерживать целостность БД.
3) Если вы хотите решить данную задачу тогда забудте про операторы Update и Delete. И вместо Update использовать Insert с новыми значением, и текущая запись становиться актуальной, для DELETE надо заводить дополнительную таблицу в которую вы будете писать идентификаторы удаленных записей. Соответственно запросы Select будут иметь совершенно другой вид.
За тем если хотим удалить действия пользователя, просто удаляем все записи с его идентификатором.

Но тут тоже очень много нюансов. Допустим, пользователь 1 ввел\удалил данные, а 2 пользователь на основе их сделал какието действия или выводы, потом почистили действия 1-го соответственно действия 2-го уже тоже не корректны. вообщем я бы это не делал бы. :)
...
Рейтинг: 0 / 0
Подскажите пару моментов по проектированию!
    #35610029
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GraDea1) Связь один-к-одному. Все время считал, что почти всегда это зло, за редким исключением. Коллега думает по-другому.
...
Только так? у нас только пункт один выполняется.Если у вас свзяь именно 1-к-1 и это не супер особый случай, то это можно слить в одну таблицу и не париться.

Но если у вас связь 1-к-1:0 - то это уже другая песня. Это часто используется.
Например вот
GraDea2) Использование справочников допустимых значений. Имеет ли смысл для всех перечислений создавать отдельные таблицы с перечислением допустимых значений. Тоже обсуждалось .

GraDea3) Не совсем имеет отношение к проектированию. Каждый пользователь подключается к базе под уникальным ИД. Необходимо разработать механизм отмены действий отдельного пользователя за укзанный период времени. Как решаются подобные задачи?А что делать с этим?

Вася 1 января - изменил название на "Зима"
Петя 1 марта - изменил название на "Весна"
Коля 1 апреля - изменил название на "Лето"
Маша 1 мая - изменила название на "Весна"

необходимо отменить действие Коли 1 апреля.

Что должно произойти?
...
Рейтинг: 0 / 0
Подскажите пару моментов по проектированию!
    #35610181
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GraDea wrote:

> 1) Связь один-к-одному. Все время считал, что почти всегда это зло, за
> редким исключением. Коллега думает по-другому.
>
> Я прав?

Не совсем. Это -- сигнал, чтобы посмотреть, всё ли в порядке.
Ну, и это совсем нормально, если связь 1:(0..1) .
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Подскажите пару моментов по проектированию!
    #35610322
GraDea
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
MasterZiv
GraDea wrote:
Не совсем. Это -- сигнал, чтобы посмотреть, всё ли в порядке.
Ну, и это совсем нормально, если связь 1:(0..1) .


пока некуда смотреть. мы на стадии проектирования. И возник спор о целесообразности разбиения таблицы на две, связанных 1:1. Хоть логически и можно выделить и те поля не всегда заполнены, мое мнение, что оно того не стоит.
...
Рейтинг: 0 / 0
Подскажите пару моментов по проектированию!
    #35610457
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GraDeaХоть логически и можно выделить и те поля не всегда заполнены, мое мнение, что оно того не стоит.Т.е. у основной таблицы может не быть деталььной записи из второй таблицы?

Ну... это тогда вобще называется "Нормальизация данных"
До какой степент ее проводить - дело тонкое.
...
Рейтинг: 0 / 0
Подскажите пару моментов по проектированию!
    #35610514
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GraDea wrote:

> пока некуда смотреть. мы на стадии проектирования.

Смотреть надо на вашу БД. НА её схему.

И возник спор о
> целесообразности разбиения таблицы на две, связанных 1:1.

Такой целесообразности нет.

Только если это разные сущности. Но у вас было в одной таблице,
значит наверное сущность одна.
А вообще вам виднее, мы -то вообщеничего нез наем.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
8 сообщений из 8, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Подскажите пару моментов по проектированию!
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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