Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Смущают меня эти зависимоти и НФ / 7 сообщений из 7, страница 1 из 1
23.06.2005, 17:50
    #33131983
bas
bas
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Смущают меня эти зависимоти и НФ
Была такая ситуация: Были таблицы Акции, Счет, Пользователь и у каждого был подтип Баланс, т.е. таблицы БалансАкции, БалансСчета, БалансПользователя, а у же по каждому балансу хронилась своя история и т.д. и т.п. И БалансАкции, БалансСчета, БалансПользователя имели сходную структуру.

Решил сделать так: таблицу Баланс, и уже на него ссылаются таблицы Акции, Счет, Пользователь.

Вроде все правильно, но смущает одно: раньше была зависимости БалансАкции->Акции, БалансСчета->Счет, БалансПользователя->Пользователь, и это правильно по логике. А сейчас получил зависимоть Акции, Счет, Пользоваль->Баланс, вроде зависимоть ничему не протеворечит, но чт-то меня смущает. Развейте мои сомнения.
...
Рейтинг: 0 / 0
24.06.2005, 06:51
    #33132466
mir
mir
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Смущают меня эти зависимоти и НФ
По-моему, первый вариант был лучше. Объединять таблицы в одну только из-за того, что у них схожая структура было не обязательно. Ведь при этом потерялось более прозрачное обеспечение целостности данных. А теперь количество возможных ошибок возросло.
...
Рейтинг: 0 / 0
24.06.2005, 07:08
    #33132473
ASCRUS
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Смущают меня эти зависимоти и НФ
basБыла такая ситуация: Были таблицы Акции, Счет, Пользователь и у каждого был подтип Баланс, т.е. таблицы БалансАкции, БалансСчета, БалансПользователя, а у же по каждому балансу хронилась своя история и т.д. и т.п. И БалансАкции, БалансСчета, БалансПользователя имели сходную структуру.

Решил сделать так: таблицу Баланс, и уже на него ссылаются таблицы Акции, Счет, Пользователь.

Вроде все правильно, но смущает одно: раньше была зависимости БалансАкции->Акции, БалансСчета->Счет, БалансПользователя->Пользователь, и это правильно по логике. А сейчас получил зависимоть Акции, Счет, Пользоваль->Баланс, вроде зависимоть ничему не протеворечит, но чт-то меня смущает. Развейте мои сомнения.
А в балансе сколько записей может быть на его держателя ? Если одна, то тогда какой смысл в данной табличке. Если множество, то я тогда не понимаю, как обьект Акция может ссылаться на баланс.
...
Рейтинг: 0 / 0
24.06.2005, 09:34
    #33132603
softwarer
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Смущают меня эти зависимоти и НФ
bas
Вопрос, который может повлиять на ответ - как именно записи маленьких таблиц объединяются в большую.

Первый вариант - через union. То есть скорее всего вводится поле "тип записи" и три записи из разных таблиц становятся тремя разнотипными записями одной таблицы. Такое преобразование по большому счету эквивалентно; достаточно представить себе, что в первом случае у Вас есть view БалансыОбщие, а во втором - соответственно три view БалансыПоТипу. Это как раз то место, где логическая и физическая модель могут различаться, если это удобно; Вы можете думать о трех логических сущностях, но реализовать их одной таблицей. Впрочем, я согласен с тем, что такая сведенная таблица в общем случае скорее хуже.

Когда так надо делать? Я бы сказал, когда общего в них существенно больше, чем разного. Когда в результате такого объединения Ваша программа избавится от заметного количества union all-ов по этим таблицам. Когда надоест писать абсолютно одинаковые хранимки, отличающиеся только именем таблицы (ну или выкручиваться из этого через динамический sql). Итп. И напротив, когда в них больше разного, когда в результате такого объединения программа обрастет кучей проверок "типа записи баланса" - так делать не надо.

Другой вариант - записи из разных таблиц сводятся в одну запись общей (более широкую), операцией типа full outer join. Если это отвечает задаче - в принципе ничего страшного не вижу. Единственно, поскольку у Вас хранится история, может оказаться, что для операции "показать историю баланса по счету" придется брать историю и отфильтровывать из нее изменения других показателей; эту операцию я бы назвал кривой и соответственно занес бы в аргументы "не делать так". Зато - так избавляемся от union-ов в операциях типа "показать историю всего"; опять тот же принцип, что и в предыдущем пункте.
...
Рейтинг: 0 / 0
24.06.2005, 13:56
    #33133440
bas
bas
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Смущают меня эти зависимоти и НФ
mirПо-моему, первый вариант был лучше. Объединять таблицы в одну только из-за того, что у них схожая структура было не обязательно. Ведь при этом потерялось более прозрачное обеспечение целостности данных. А теперь количество возможных ошибок возросло.
Согласен, но плодить на каждую сущность по подтипу, который по структуре и логике обработки ничем не отличается, это же тоже не верно.
Причем у каждого подтипа БалансАкции, БалансСчета, БалансПользователя были свои 2 таблицы (которые были одинаковы по структуре между 2 мя такими же таблицами у другого подтипа), в кот. хранилась история изменния баланса и история измения состояний этого баланса (закрыт, открыт и т.д.)

ASCRUSА в балансе сколько записей может быть на его держателя ?
Да по одной, т.е. это был подтип. Это было сделано для более прозрачной реализации и не зависимости изменние отрибутов основной сущности и изменние атрибутов подтипа, т.к. система ярко выраденная OLTP, то это важный момент

softwarerВопрос, который может повлиять на ответ - как именно записи маленьких таблиц объединяются в большую
Никак, т.е. БалансАкции никак не обединяются с БалансСчета и т.д.

З.Ы. Т.е. как я понял все скланяются к тому, чтобы сделать по 3 одинаковых таблицы (т.е. подтип и 2 таблицы с историей) на каждую сущность?!
...
Рейтинг: 0 / 0
24.06.2005, 16:45
    #33134009
Estets
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Смущают меня эти зависимоти и НФ
softwarer
Впрочем, я согласен с тем, что такая сведенная таблица в общем случае скорее хуже.

На мой взгляд если структура таблиц схожая то и отчеты по ним должны быть схожие. Следовательно хранение данных в одной таблице предпочтительнее. Т.к. нужен будет 1 вариант отчета и параметром вместо нескольких.
...
Рейтинг: 0 / 0
25.06.2005, 12:17
    #33134647
softwarer
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Смущают меня эти зависимоти и НФ
EstetsТ.к. нужен будет 1 вариант отчета и параметром вместо нескольких.
Я дал вполне строгий, математический критерий: сводить стоит, если таким образом избавимся от большего количества union all, нежели добавим условий вида record_type = X. Вы говорите свободным языком примерно то же, только.. в довольно возражабельной форме. Почему возражабельной - потому что каждый из нас наверняка видел такие вот "один отчет на все", в котором почти невозможно разобраться, как же он работает, и задача "сделать вот это поле на сантиметр шире" приводит к неработоспособности остальных десяти видов отчетов, реализуемых тем же модулем.
...
Рейтинг: 0 / 0
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Смущают меня эти зависимоти и НФ / 7 сообщений из 7, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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