|
|
|
Подскажите пару моментов по проектированию!
|
|||
|---|---|---|---|
|
#18+
Всем привет! Предметная область - высшее образование Наверняка все это обсуждалось. 1) Связь один-к-одному. Все время считал, что почти всегда это зло, за редким исключением. Коллега думает по-другому. Я прав? Какие доводы в пользу меня, а какие против? Нашел обсуждение данной проблемы Marat_LПожалуй да. Иногда наверное надо. Например в случаях когда 1) Часть полей по логическому содержанию можно объединить в отдельную группу 2) Эта часть полей очень часто модифицируется 3) В таблице много других полей с индексами, которые обновляются значительно реже 4) А самое главное вычислительные издержки на 2) ощутимо превосходят издержки на объединение (хотя это трудно оценить) Только так? у нас только пункт один выполняется. 2) Использование справочников допустимых значений. Имеет ли смысл для всех перечислений создавать отдельные таблицы с перечислением допустимых значений. 3) Не совсем имеет отношение к проектированию. Каждый пользователь подключается к базе под уникальным ИД. Необходимо разработать механизм отмены действий отдельного пользователя за укзанный период времени. Как решаются подобные задачи? Заранее спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2008, 13:40:27 |
|
||
|
Подскажите пару моментов по проектированию!
|
|||
|---|---|---|---|
|
#18+
GraDeaВсем привет! 3) Не совсем имеет отношение к проектированию. Каждый пользователь подключается к базе под уникальным ИД. Необходимо разработать механизм отмены действий отдельного пользователя за укзанный период времени. Как решаются подобные задачи? Заранее спасибо! Решается журналированием (регистрацией) проведенных пользователем изменений и проведением "обратных" преобразований... Вот только привилегии у пользователей могут быть разные. И действия, выполняемые ими, тоже... Например, возможна такая проблема: один из суперпользователей ввел колонку в таблицу, другие (обычные) пользователи затем "навводили" в эту колонку значений... Затем, в один прекрасный день, среди прочих действий суперпользователя надо откатить добавление колонки в таблицу... Но тогда сделаем неактуальной "кучу" записей в журнале по вводу/изменению данных в указанную колонку... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2008, 15:01:24 |
|
||
|
Подскажите пару моментов по проектированию!
|
|||
|---|---|---|---|
|
#18+
1) cвязь 1 к 1 бывает очень полезна когда у вас "Широкие" таблицы. Тут все зависит от данных и типов запросов. Сразу и не скажешь. 2) Однозначно да, что бы поддерживать целостность БД. 3) Если вы хотите решить данную задачу тогда забудте про операторы Update и Delete. И вместо Update использовать Insert с новыми значением, и текущая запись становиться актуальной, для DELETE надо заводить дополнительную таблицу в которую вы будете писать идентификаторы удаленных записей. Соответственно запросы Select будут иметь совершенно другой вид. За тем если хотим удалить действия пользователя, просто удаляем все записи с его идентификатором. Но тут тоже очень много нюансов. Допустим, пользователь 1 ввел\удалил данные, а 2 пользователь на основе их сделал какието действия или выводы, потом почистили действия 1-го соответственно действия 2-го уже тоже не корректны. вообщем я бы это не делал бы. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2008, 16:11:56 |
|
||
|
Подскажите пару моментов по проектированию!
|
|||
|---|---|---|---|
|
#18+
GraDea1) Связь один-к-одному. Все время считал, что почти всегда это зло, за редким исключением. Коллега думает по-другому. ... Только так? у нас только пункт один выполняется.Если у вас свзяь именно 1-к-1 и это не супер особый случай, то это можно слить в одну таблицу и не париться. Но если у вас связь 1-к-1:0 - то это уже другая песня. Это часто используется. Например вот GraDea2) Использование справочников допустимых значений. Имеет ли смысл для всех перечислений создавать отдельные таблицы с перечислением допустимых значений. Тоже обсуждалось . GraDea3) Не совсем имеет отношение к проектированию. Каждый пользователь подключается к базе под уникальным ИД. Необходимо разработать механизм отмены действий отдельного пользователя за укзанный период времени. Как решаются подобные задачи?А что делать с этим? Вася 1 января - изменил название на "Зима" Петя 1 марта - изменил название на "Весна" Коля 1 апреля - изменил название на "Лето" Маша 1 мая - изменила название на "Весна" необходимо отменить действие Коли 1 апреля. Что должно произойти? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2008, 18:00:20 |
|
||
|
Подскажите пару моментов по проектированию!
|
|||
|---|---|---|---|
|
#18+
GraDea wrote: > 1) Связь один-к-одному. Все время считал, что почти всегда это зло, за > редким исключением. Коллега думает по-другому. > > Я прав? Не совсем. Это -- сигнал, чтобы посмотреть, всё ли в порядке. Ну, и это совсем нормально, если связь 1:(0..1) . Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2008, 19:17:43 |
|
||
|
Подскажите пару моментов по проектированию!
|
|||
|---|---|---|---|
|
#18+
MasterZiv GraDea wrote: Не совсем. Это -- сигнал, чтобы посмотреть, всё ли в порядке. Ну, и это совсем нормально, если связь 1:(0..1) . пока некуда смотреть. мы на стадии проектирования. И возник спор о целесообразности разбиения таблицы на две, связанных 1:1. Хоть логически и можно выделить и те поля не всегда заполнены, мое мнение, что оно того не стоит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2008, 21:39:35 |
|
||
|
Подскажите пару моментов по проектированию!
|
|||
|---|---|---|---|
|
#18+
GraDeaХоть логически и можно выделить и те поля не всегда заполнены, мое мнение, что оно того не стоит.Т.е. у основной таблицы может не быть деталььной записи из второй таблицы? Ну... это тогда вобще называется "Нормальизация данных" До какой степент ее проводить - дело тонкое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2008, 23:13:06 |
|
||
|
Подскажите пару моментов по проектированию!
|
|||
|---|---|---|---|
|
#18+
GraDea wrote: > пока некуда смотреть. мы на стадии проектирования. Смотреть надо на вашу БД. НА её схему. И возник спор о > целесообразности разбиения таблицы на две, связанных 1:1. Такой целесообразности нет. Только если это разные сущности. Но у вас было в одной таблице, значит наверное сущность одна. А вообще вам виднее, мы -то вообщеничего нез наем. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2008, 00:09:31 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=35609146&tid=1543614]: |
0ms |
get settings: |
8ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
180ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
33ms |
get tp. blocked users: |
1ms |
| others: | 196ms |
| total: | 443ms |

| 0 / 0 |
