АЩ
Size: a a a
2019 December 30
W
Я просто пока принипиально не хочу лезть в скрипт загрузи данных... ПонялтнО, что удобнее это все распилить на этапе внесения в систему... но не очень хочется...
Так и не надо в скрипт. Судя по картинке, это разные сущности, одна из которых детализируется по месяцам, а другая - нет. Соответственно, грузим в разные таблицы с подходящими ключами для связи.
IS
Whiteline
Так и не надо в скрипт. Судя по картинке, это разные сущности, одна из которых детализируется по месяцам, а другая - нет. Соответственно, грузим в разные таблицы с подходящими ключами для связи.
поддерживаю, только не желательно такое делать на больших объемах данных, так как всё будет безбожно тупить. Если есть более одного вида фактов в приложении, лучше постараться реализовать это через конкатенацию, нежели через связь
IS
и судя по картинке, там сущность одна, просто в разных разрезах, где-то она GRP20, а где-то по возрастным когортам, видимо, поделена... тут не про модели данных а про нормализацию надо почитать и всё станет на свои места =)
IS
W
Ivan Sokolov
поддерживаю, только не желательно такое делать на больших объемах данных, так как всё будет безбожно тупить. Если есть более одного вида фактов в приложении, лучше постараться реализовать это через конкатенацию, нежели через связь
Оптимизация, это уже следующий уровень ) Всё же "большие объемы" в каждой конкретной ситуации свои. Кроме того, переход к одной таблице, это просто следующий шаг преобразования. А на больших объемах придется ещё изучать, почему надо join, а не concatenate. Или вообще, получать плоскую таблицу нужной структуры из другой системы.
IS
Whiteline
Оптимизация, это уже следующий уровень ) Всё же "большие объемы" в каждой конкретной ситуации свои. Кроме того, переход к одной таблице, это просто следующий шаг преобразования. А на больших объемах придется ещё изучать, почему надо join, а не concatenate. Или вообще, получать плоскую таблицу нужной структуры из другой системы.
да-да, боль та ещё =)
АЩ
Whiteline
Так и не надо в скрипт. Судя по картинке, это разные сущности, одна из которых детализируется по месяцам, а другая - нет. Соответственно, грузим в разные таблицы с подходящими ключами для связи.
На скрине исходные данные. Я их Ника не обрабатывал. По факту, я один и тот же файл загрузил под разными именами сформировал средствами клика уникальный ключ (как объединение полей) и связал эти таблицы между собой, из одной взяв один набор полей а из второй только ключ и разобъедиенныую таблицу аудиторий.
АЩ
Ivan Sokolov
и судя по картинке, там сущность одна, просто в разных разрезах, где-то она GRP20, а где-то по возрастным когортам, видимо, поделена... тут не про модели данных а про нормализацию надо почитать и всё станет на свои места =)
Вы не в контексте. Это разные сущности. Одна называется GRP , а вторая э, которая в разрезе аудиторий -- TRP. GRP можно складывать, trp складывать нельзя. То есть сумма двух трп для разных аудиторий не равна сумме значений. Короче, там не все так лилейно, как кажется по картинке.
IS
хм... жалко что не понимаю сути задачи, но, уверен, что можно привести данные к линейности... или, как минимум, сделать как вам сразу посоветовали - грузите в разные таблицы эти данные и всё будет ок, ничего не будет задваиваться дублироваться, посчитается один раз =)
АЩ
Входящие данные содержат поля: дата, фамилия, сумма дохода, траты на еду, траты на дом, траты на семью.
АЩ
Если просто разобъкдинить траты, превратив их в два поля: тип траты, сумма траты. То сумма дохода утроится.
АЩ
Поэтому, мы берём изначальную таблицу, и грузим ее под двумя именами : доходы, расходы.
АЩ
В обе таблицы добавляем уникальный ключ, дата&фамилия
АЩ
Из одной таблицы берём, фамилию, дату, сумму дохода, ключ.
АЩ
Из второй таблицы разобъединяем поля траты, формируя 2 поля: тип траты, сумма траты.
АЩ
И из нее забираем ключ, тип траты, сумма траты
АЩ
Связываем таблицы между собой.
АЩ
Профит.
АЩ
Тут тоже самое, только с колонками grp и all...