|
|
|
План/факт. Хранение информации
|
|||
|---|---|---|---|
|
#18+
Здравствуйте. Сегодня был пустой спор. На мой взгляд. Допустим нам нужно хранить 10 атрибутов, 4 из них образуют составной ключ и по три на план и факт для идентичных качественных показателей. Мне пытались доказать что необходимо создавать две таблицы. Я пытался доказать что таких ситуаций не существует. Но мой соперник был настолько наглый что у меня не нашлось нужных слов. Подскажите пожалуйста их, если я прав. Или я что-то упускаю ? Модератор: Тема перенесена из форума "Microsoft SQL Server". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2014, 11:09 |
|
||
|
План/факт. Хранение информации
|
|||
|---|---|---|---|
|
#18+
Если есть записи с планом, но без факта, или наоборот, то вариант с одной таблицей хуже. Количество записей к чтению будет больше, и иногда придется писать условия на <> 0. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2014, 11:26 |
|
||
|
План/факт. Хранение информации
|
|||
|---|---|---|---|
|
#18+
SashaMercuryЗдравствуйте. Сегодня был пустой спор. На мой взгляд. Допустим нам нужно хранить 10 атрибутов, 4 из них образуют составной ключ и по три на план и факт для идентичных качественных показателей. Если план и факт полностью идентичны - один из них лишний :) Гхостик Если есть записи с планом, но без факта, или наоборот, то вариант с одной таблицей хуже Я бы сказал "... вариант с одной записью хуже". Хранить запись "План" и запись "Факт", различающиеся флагом, можно и в одной таблице ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2014, 12:20 |
|
||
|
План/факт. Хранение информации
|
|||
|---|---|---|---|
|
#18+
SashaMercuryЗдравствуйте. Сегодня был пустой спор. На мой взгляд. Допустим нам нужно хранить 10 атрибутов, 4 из них образуют составной ключ и по три на план и факт для идентичных качественных показателей. Мне пытались доказать что необходимо создавать две таблицы. Я пытался доказать что таких ситуаций не существует. Но мой соперник был настолько наглый что у меня не нашлось нужных слов. Подскажите пожалуйста их, если я прав. Или я что-то упускаю ? План это план, а факт это факт и вместе им не сойтись... Это разные сущности. Кроме того планов может быть много, а факт всегда один. Т.е. на один и тот же период может быть более одного плана, по одним и тем же атрибутам. А вот факт будет только один. Кроме того факт != план. Так что лучше хранить план и факт отдельно. Т.к. сущности план и факт не идентичные сущности. Т.е. существуют атрибуты которые есть в плане, но нет в факте. И наоборот. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2014, 15:20 |
|
||
|
План/факт. Хранение информации
|
|||
|---|---|---|---|
|
#18+
> был пустой спор Это не пустой спор. Вы смотрите на один из частных случаев. > Я пытался доказать что таких ситуаций не существует Интересно, как именно пытались? Можно услышать ваши аргументы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2014, 16:31 |
|
||
|
План/факт. Хранение информации
|
|||
|---|---|---|---|
|
#18+
SashaMercuryЗдравствуйте. Сегодня был пустой спор. На мой взгляд. Допустим нам нужно хранить 10 атрибутов, 4 из них образуют составной ключ и по три на план и факт для идентичных качественных показателей. Мне пытались доказать что необходимо создавать две таблицы. Я пытался доказать что таких ситуаций не существует. Но мой соперник был настолько наглый что у меня не нашлось нужных слов. Подскажите пожалуйста их, если я прав. Или я что-то упускаю ? Модератор: Тема перенесена из форума "Microsoft SQL Server". Если речь о значениях показателей. OLAP. Пример: Страна, Театр, Артист, Месяц: Кол. спектаклей (план), Количество спектакле (факт), Кол. полученных букетов (план), Кол. полученных букетов (факт), Кол. драк с коллегами (план), Кол драк с коллегами (факт). Измерения (первые Ваши четыре атрибута), и меры (три пары атрибутов). Данные берутся из OLTP, предположим, после завершения некого периода. То есть, это агрегированные данные. Тогда Ваше решение имеет право на существование. Поскольку, если и будет "две таблицы" (два показателя по три меры в каждом), или шесть таблиц (шесть показателей по одной мере в каждом), то все равно должна быть предусмотрена операция манипулирования, которая даст этот самый показатель с шестью мерами. И возникает предположение - а почему же сразу не сделать именно одну такую "таблицу")) Тем не менее, вопрос дискуссионный по многим-многим причинам)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2014, 21:17 |
|
||
|
План/факт. Хранение информации
|
|||
|---|---|---|---|
|
#18+
наверное стоит для начала определиться об OLTP или DWH идет речь. Для OLTP выбор может зависить от планируемого объема данных и выборок по нему. Строго говоря "план" может быть, а "факт" может и не существовать или появляться/заполняться позднее. Поэтому, в случае с одной таблицей будет большое кол-во null-ов или 0 что вобщем то для OLTP выглядит не очень хорошо. Для DWH скорее все следует денормализовать и свести в все одну таблицу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2014, 22:04 |
|
||
|
План/факт. Хранение информации
|
|||
|---|---|---|---|
|
#18+
SashaMercury, При планировании и анализе план/факт гранулярность (степень детализации) определяется двумя сущностями: 1. Объект планирования 2. Период планирования Как правило "сырые" фактические данные имеют другую гранулярность, чем План (то есть бОльшую степень детализации). Поэтому Факт (для План/Факта) агрегируется до минимальной гранулярности Плана. Например, для оперативного планирования продаж розничной сети факты продаж (строки чеков) агрегируются до: 1. Категория продуктов / Точка продаж (магазин) 2. Неделя продаж (по календарю 52 недели == 4 х 13) Понятно, что и собственно планирование, и анализ План/Факт подразумевают работу с несколькими источниками (схемами) данных. Одной таблицей тут не обойтись :-) Ваш спор был видимо о том, в каком виде хранить некоторые результаты анализа План/Факт . Здесь уже действует правило "на вкус и цвет..." :-) Удачи ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.02.2014, 01:35 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=38570558&tid=1540958]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
177ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
52ms |
get tp. blocked users: |
2ms |
| others: | 13ms |
| total: | 287ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...