Вопрос: как правильно спроектировать таблицу
Нужно хранить логистические данные для последующего статистического анализа
Вопрос в том - какой вариант проектирования лучше ? (идеологически, и по быстродействию)
А то я про нормальные формы читал, но так и не вкурил к какой форме относятся эти 2 варианта.
Имеются связи с: т. Товары, т. Магазины, табл. Поставщики
Вариант 1: с 1й таблицей "Операции":
Поля: Н_недели, Товары_код, Магазины_код (ключевые), количество_закупки, цена_закуп, количество_продажи, цена_розн, количество_перемещения, количество_наличие, ну и поставщики_код итд.
Вариант 2 - разбить на 4 таблицы: Закупки, Продажи, Перемещения, Наличие
В каждой те же 3 ключевых поля Н_недели, Товары_код, Магазины_код, + специфика
В 1 варианта естественно, некоторые поля будут null
Объем БД - 3-4млн строк для таблицы Операции (1й вариант проектирования) или для таблицы Наличие, другие таблицы в несколько (или несколько десятков) раз меньше
Вопрос в том - какой вариант проектирования лучше ? (идеологически, и по быстродействию)
А то я про нормальные формы читал, но так и не вкурил к какой форме относятся эти 2 варианта.
Имеются связи с: т. Товары, т. Магазины, табл. Поставщики
Вариант 1: с 1й таблицей "Операции":
Поля: Н_недели, Товары_код, Магазины_код (ключевые), количество_закупки, цена_закуп, количество_продажи, цена_розн, количество_перемещения, количество_наличие, ну и поставщики_код итд.
Вариант 2 - разбить на 4 таблицы: Закупки, Продажи, Перемещения, Наличие
В каждой те же 3 ключевых поля Н_недели, Товары_код, Магазины_код, + специфика
В 1 варианта естественно, некоторые поля будут null
Объем БД - 3-4млн строк для таблицы Операции (1й вариант проектирования) или для таблицы Наличие, другие таблицы в несколько (или несколько десятков) раз меньше
Мне кажется, что лучше сделать две таблички.
1- тип операции (Закупки, Продажи, Перемещения, Наличие).
2- операции (Ключи: Товар, Магазин, Поставщик, тип операции; Поля - Объем, Сумма).
1- тип операции (Закупки, Продажи, Перемещения, Наличие).
2- операции (Ключи: Товар, Магазин, Поставщик, тип операции; Поля - Объем, Сумма).
Цитата: Sonia
Мне кажется, что лучше сделать две таблички.
1- тип операции (Закупки, Продажи, Перемещения, Наличие).
2- операции (Ключи: Товар, Магазин, Поставщик, тип операции; Поля - Объем, Сумма).
1- тип операции (Закупки, Продажи, Перемещения, Наличие).
2- операции (Ключи: Товар, Магазин, Поставщик, тип операции; Поля - Объем, Сумма).
Это 3й вариант :)
Но:
1. Поставщик будет null в строках, относящихся к другой операции
2. Для разных операций нужны разные поля данных.
Для Закупок: цена, количество, поставщик
Для Продажи: цена (которая=цене из наличия), количество
Для Перемещения: только количество
Для Наличия: цена, количество
Если ввести их все в таблицу, то будет много null-ов
Пока я склоняюсь к варианту с 4 таблицами (на каждую операцию) - там хотя бы нет null-ов. Но т.к. я уже начал переводить базу в вариант 2 (пытался оптимизировать размер БД, а потом оказалось, что надо просто указать СУБД чтобы он почистил файлы...) было бы обидно отказаться от этого переноса, если потом окажется что все таки 2й вариант правильней...
"правильного" решения здесь не существует, надо исходить из того, какая реально обработка понадобится для этих данных, какие отчеты...
Попробуйте копнуть в сторону организации хранилищь данных, OLAP, как раз ваша тема.
У вас получается одна таблица фактов "Операции" и таблицы измерений которые ее описывают. Либо четыре различных таблицы фактов по типам операции.
Соответвенно, если в большинстве отчетов вам понадобятся сводные данные по всем операциям. Например, вывести количество операций с конкретным товаром за определенный период или что-то вроде этого. Одна таблица удобнее, не надо выполнять соединений. Если будет 4 таблицы - много милиоонные соединения будут явно медленнее, чем запрос по одной таблице.
Так же если количество полей фиксирвоанно и вы можете с большой долей вероятности сказать, что они не будут меняться то лучше сделать одну таблицу.Если же например к Продажам вдруг завтра добавится колонка Менеджер, а к Перемещению послезавтра вдруг добавится колонка Транспорто_средство и вас будет интересовать аналитика, статистика по этим колонкам - лучше выделить в разные таблицы. Т.е. смотреть нужно исходя из реальной задачи, а не решая теоретический вопрос.
Умеренная денормализация в виде "лишних" колонок пусть вас особо не беспокоит, в OLAP ее иногда применяют для улучшения произодительности,а значения НУЛЛ (если уж так вас они настораживают) всегда можно заменить заполнителями, плюс правильно построить индексы по таблице.
Короче мой совет, если статистические отчеты вполне определенные и не будут часто видоизменяться, если не будет очень специфических отчетов по конкретно операции - оставляйте все в одной таблице фактов.
Ну и погуглите на тему OLAP, DWH, ибо все написанное выше только мое мнение и я в OLAP и DWH не считаю себя экспертом...
Попробуйте копнуть в сторону организации хранилищь данных, OLAP, как раз ваша тема.
У вас получается одна таблица фактов "Операции" и таблицы измерений которые ее описывают. Либо четыре различных таблицы фактов по типам операции.
Соответвенно, если в большинстве отчетов вам понадобятся сводные данные по всем операциям. Например, вывести количество операций с конкретным товаром за определенный период или что-то вроде этого. Одна таблица удобнее, не надо выполнять соединений. Если будет 4 таблицы - много милиоонные соединения будут явно медленнее, чем запрос по одной таблице.
Так же если количество полей фиксирвоанно и вы можете с большой долей вероятности сказать, что они не будут меняться то лучше сделать одну таблицу.Если же например к Продажам вдруг завтра добавится колонка Менеджер, а к Перемещению послезавтра вдруг добавится колонка Транспорто_средство и вас будет интересовать аналитика, статистика по этим колонкам - лучше выделить в разные таблицы. Т.е. смотреть нужно исходя из реальной задачи, а не решая теоретический вопрос.
Умеренная денормализация в виде "лишних" колонок пусть вас особо не беспокоит, в OLAP ее иногда применяют для улучшения произодительности,а значения НУЛЛ (если уж так вас они настораживают) всегда можно заменить заполнителями, плюс правильно построить индексы по таблице.
Короче мой совет, если статистические отчеты вполне определенные и не будут часто видоизменяться, если не будет очень специфических отчетов по конкретно операции - оставляйте все в одной таблице фактов.
Ну и погуглите на тему OLAP, DWH, ибо все написанное выше только мое мнение и я в OLAP и DWH не считаю себя экспертом...