Это зависит от множества факторов, но в целом добавление столбца идентификатора пользователя будет способом архитектурного решения. В первую очередь это связано с тем, что в табличном виде данные хранятся в сжатом формате хранилища столбцов . Самый простой способ объяснить это состоит в том, что таблица содержит только одну копию каждого уникального значения со словарем о том, как это значение связано с остальными столбцами.
Итак, давайте посмотрим, как это работает, на примере. Мы создадим таблицу с идентификатором пользователя и одним столбцом данных. Поскольку мы говорим о такой узкой таблице, я собираюсь рассматривать строку в реляционной базе данных так же, как запись в нашей табличной модели.
- 100 пользователей
- 500 тыс. Записей на пользователя
- 2 столбца (идентификатор пользователя и столбец данных)
- 10 тыс. Уникальных значений в нашем столбце данных
В традиционной реляционной базе данных у нас будет
- 100 пользователей x 500 тыс. Записей = 50 миллионов единиц (ай!)
Если бы мы поместили каждого пользователя в уникальную таблицу или модель в виде таблицы, то мы получили бы
- 100 моделей (пользователей) x 10k уникальных значений = 1 миллион элементов (вероятно, немного меньше, поскольку каждый пользователь может иметь не все значения 10k)
Однако, если мы создадим одну таблицу с идентификатором пользователя и столбцом данных, мы получим
- 100 пользователей в магазине с одним столбцом + 10 000 уникальных значений в другом магазине = 10 100 наименований
Конечно, отдельные значения в табличной форме занимают больше места, чем в большинстве реляционных баз данных, но тот факт, что вы храните одну копию каждого значения, обычно компенсирует это с огромным запасом.
Как видите, причина, по которой мы хотим идти по этому пути, заключается в том, что мы добавляем количество возможных значений для каждого столбца вместо их умножения. Ключ к получению представления о количестве уникальных значений для каждого столбца. Если у вас есть открытые строки где-то, где почти каждое значение уникально, то сжатие будет минимальным. Поскольку большая часть данных для анализа основана на числах, датах и строках, которые имеют ограниченное количество уникальных значений, в этом типе хранилища все хорошо сжимается. Это действительно увеличивает количество объединений, так как каждый столбец является своего рода таблицей, но тот факт, что таблица работает на 100% в памяти, восполняет это.
Надеюсь, этого достаточно, чтобы вы начали. Если вы хотите узнать больше о том, как организовать ваши данные, чтобы быть эффективными в табличной модели, я бы посоветовал узнать, как работает схема снежинка . Для таблиц служб аналитики, в частности, Парень в кубе и sqlbi.com являются отличными ресурсами. Большая часть их контента посвящена Power BI, но модели данных Power BI - это просто табличные кубы. Они оба используют движок Vertipaq для хранения и запроса данных.