Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Структура базы данных.  [new]
vladka63
Member

Откуда:
Сообщений: 1688
Добрый день.

Совет нужен, уважаемые коллеги.

Суть в следующем:
у сайта, в базе данных, есть таблица Product.
В этой таблице около 60 полей.
Реально, по товарам, в комбинациях задействовано около 40 полей.

И из этой таблицы продукты выводятся на страницы сайта.

Теперь возникла задача.
Нужно добавить на сайт еще один вид продуктов.
Но дело в том, что для этого вида продуктов будет нужно всего 3 поля из 60, остальные поля будут заполняться значениями по умолчанию (null, true, false)и в общем то, эти значения по умолчанию никогда не будут влиять на вывод нового продукта на страницу (в смысле функции). Т.е, просто чтобы запросы корректно обрабатывались и все.

Вопрос: на ваш новый продукт помещать в имеющуюся таблицу или лучше создать новую таблицу с 3-я полями?

Вопрос возник в связи с тем, что: а имеет ли смысл при каждом запросе обрабатывать 60 полей, если точно понятно, что выведет только 3..

Спасибо.
5 окт 18, 08:53    [21695973]     Ответить | Цитировать Сообщить модератору
 Re: Структура базы данных.  [new]
Щукина Анна
Member

Откуда:
Сообщений: 1466
vladka63,

а завтра появится продукт с пятью полями - ещё таблицу делать будете? а послезавтра нужно будет семь полей, затем десять.
на каждый такой чих будете по таблице делать?

Если уж и городить новые таблицы и есть возможность менять структуру базы и работающий с ней код, то лучше заняться нормализацией и перепроектировать всю базу по новой...
5 окт 18, 08:58    [21695976]     Ответить | Цитировать Сообщить модератору
 Re: Структура базы данных.  [new]
vladka63
Member

Откуда:
Сообщений: 1688
Щукина Анна
vladka63,

а завтра появится продукт с пятью полями - ещё таблицу делать будете? а послезавтра нужно будет семь полей, затем десять.
на каждый такой чих будете по таблице делать?

Если уж и городить новые таблицы и есть возможность менять структуру базы и работающий с ней код, то лучше заняться нормализацией и перепроектировать всю базу по новой...


Есть логика в вашем ответе, Анна. Бесспорно есть..
А завтра их будет 15..


Хорошо, а что бы вы посоветовали, если бы этого "завтра" не было.
Т.е, точно известно - что единожды будет добавлено наименование с описанием в трех полях.
5 окт 18, 09:02    [21695981]     Ответить | Цитировать Сообщить модератору
 Re: Структура базы данных.  [new]
Щукина Анна
Member

Откуда:
Сообщений: 1466
vladka63,

ещё раз, если в первый раз эта мысль была озвучена не достаточно ясно:
заняться нормализацией базы. хотя бы до третьей нормальной формы
5 окт 18, 09:11    [21695987]     Ответить | Цитировать Сообщить модератору
 Re: Структура базы данных.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30768
vladka63
Есть логика в вашем ответе, Анна. Бесспорно есть..
А завтра их будет 15..

Хорошо, а что бы вы посоветовали, если бы этого "завтра" не было.
Т.е, точно известно - что единожды будет добавлено наименование с описанием в трех полях.
Не надо делать разные таблицы для одной бизнес-сущности, потом будет неудобно с этим работать.

Если не стоит остро вопрос оптимизации хранения (например, там миллиарды записей), то лучше оставить всё в одной таблице.
5 окт 18, 09:15    [21695989]     Ответить | Цитировать Сообщить модератору
 Re: Структура базы данных.  [new]
vladka63
Member

Откуда:
Сообщений: 1688
alexeyvg
vladka63
Есть логика в вашем ответе, Анна. Бесспорно есть..
А завтра их будет 15..

Хорошо, а что бы вы посоветовали, если бы этого "завтра" не было.
Т.е, точно известно - что единожды будет добавлено наименование с описанием в трех полях.
Не надо делать разные таблицы для одной бизнес-сущности, потом будет неудобно с этим работать.

Если не стоит остро вопрос оптимизации хранения (например, там миллиарды записей), то лучше оставить всё в одной таблице.


Спасибо, понял :-)
5 окт 18, 09:17    [21695993]     Ответить | Цитировать Сообщить модератору
 Re: Структура базы данных.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30768
Щукина Анна
vladka63,

ещё раз, если в первый раз эта мысль была озвучена не достаточно ясно:
заняться нормализацией базы. хотя бы до третьей нормальной формы
Мне вот непонятно, как это сделать на практике?

Вот у нас есть продукция, там есть записи Экскаваторы и Бульдозеры
У экскаваторов есть атрибут "объём ковша", у бульдозеров нет
Вполне типичная ситуация для любой торговой фирмы, например. Только там 100500 типов товаров, а не два.

Как следует поступить? Делать 2 таблицы? Делать EAV? Делать связанные сущности свойства экскаватора/бульдозера?

ИМХО вполне нормальным является вариант, когда в таблицу запихивают все атрибуты, а заполняют подходящие, хотя, конечно, тут есть недостатки.
5 окт 18, 09:21    [21695997]     Ответить | Цитировать Сообщить модератору
 Re: Структура базы данных.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30768
alexeyvg
Вот у нас есть продукция, там есть записи Экскаваторы и Бульдозеры
У экскаваторов есть атрибут "объём ковша", у бульдозеров нет
Вполне типичная ситуация для любой торговой фирмы, например. Только там 100500 типов товаров, а не два.

Как следует поступить? Делать 2 таблицы? Делать EAV? Делать связанные сущности свойства экскаватора/бульдозера?

ИМХО вполне нормальным является вариант, когда в таблицу запихивают все атрибуты, а заполняют подходящие, хотя, конечно, тут есть недостатки.
Вообще, такое квалифицированно обсуждают в Проектировании БД, но выскажу такую мысль - нужно исходить из бизнес-смысла этих таблиц.

Если для бизнеса это только "Продукция", то нужно делать одну таблицу. Или одну таблицу, + EAV для свойств.

Если для бизнеса это разные по смыслу сущности, то не надо объединять их в одной таблице. Тогда стандартный подход - делать таблицу Продукция, и 2 подчинённых таблицы со связью 1-1, с специфическим набором атрибутов.

Ну и отдельные решения для особых случаев - большая нагрузка, либо большой объём.
5 окт 18, 09:30    [21696006]     Ответить | Цитировать Сообщить модератору
 Re: Структура базы данных.  [new]
Владимир Затуливетер
Member

Откуда:
Сообщений: 427
Полностью согласен с alexeyvg.
Лучше сделать в одной таблице иначе будет просто неудобно работать с этим данными.

А хранение данных всегда можно оптимизировать.
  • data-compression
  • column-sets
  • sparse-columns
  • 5 окт 18, 11:18    [21696118]     Ответить | Цитировать Сообщить модератору
     Re: Структура базы данных.  [new]
    TaPaK
    Member

    Откуда: Kiev
    Сообщений: 6794
    автор
    А хранение данных всегда можно оптимизировать.
    data-compression
    column-sets
    sparse-columns

    форум всё хуже и хуже....

    EAV если нет понимания конечного масштабирования, или на 2 таблицы объект с основными для всех параметрами + таблица EAV к ней
    5 окт 18, 11:23    [21696123]     Ответить | Цитировать Сообщить модератору
     Re: Структура базы данных.  [new]
    Владислав Колосов
    Member

    Откуда:
    Сообщений: 7399
    alexeyvg,

    это делается путем создания таблицы, в которой хранятся пары типа "ключ-значение".
    5 окт 18, 11:57    [21696188]     Ответить | Цитировать Сообщить модератору
     Re: Структура базы данных.  [new]
    TaPaK
    Member

    Откуда: Kiev
    Сообщений: 6794
    Владислав Колосов
    alexeyvg,

    это делается путем создания таблицы, в которой хранятся пары типа "ключ-значение".

    он так и сказал EAV
    5 окт 18, 12:01    [21696199]     Ответить | Цитировать Сообщить модератору
     Re: Структура базы данных.  [new]
    256k
    Member

    Откуда: с.Торчилово, Псковская обл.
    Сообщений: 437
    Владимир Затуливетер
    Полностью согласен с alexeyvg.
    Лучше сделать в одной таблице иначе будет просто неудобно работать с этим данными.

    А хранение данных всегда можно оптимизировать.
  • data-compression
  • column-sets
  • sparse-columns


  • всегда или нет, еще вопрос, юзер не указал версию сервера
    5 окт 18, 13:05    [21696312]     Ответить | Цитировать Сообщить модератору
     Re: Структура базы данных.  [new]
    PizzaPizza
    Member

    Откуда:
    Сообщений: 309
    alexeyvg
    Щукина Анна
    vladka63,

    ещё раз, если в первый раз эта мысль была озвучена не достаточно ясно:
    заняться нормализацией базы. хотя бы до третьей нормальной формы
    Мне вот непонятно, как это сделать на практике?

    Вот у нас есть продукция, там есть записи Экскаваторы и Бульдозеры
    У экскаваторов есть атрибут "объём ковша", у бульдозеров нет
    Вполне типичная ситуация для любой торговой фирмы, например. Только там 100500 типов товаров, а не два.

    Как следует поступить? Делать 2 таблицы? Делать EAV? Делать связанные сущности свойства экскаватора/бульдозера?

    ИМХО вполне нормальным является вариант, когда в таблицу запихивают все атрибуты, а заполняют подходящие, хотя, конечно, тут есть недостатки.


    ИМХО зависит от количества продуктов...

    У меня есть несколько источников данных (продукция), с каждого приходят разные наборы параметров (атрибуты) которые надо хранить. единственное ограничение, атрибуты все одного типа. У меня все int.

    Я храню
    продукты с описанием (id_product, name, etc) (1, экскаватор Э1, дорогой, красивый), (2, бульдозер БМ, дешевый, молодежный)
    все параметры продуктов в одной таблице (id_product, id_param_name, value) (1,100,60)
    наименования параметров в библиотеке (id_param_name, param_name)(100, скорость)

    то есть для любого продукта тут может быть любое количество атрибутов и никаких null

    Дальше удобно делать пивотом отчет по известному мне сету параметров или же делать группы параметров в библиотеке (id_param_name, param_name, id_group) и собирать запрос по ним. Опять же в библиотеку можно вынести особенности атрибутов (id_param_name, param_name, type, group) (100, скорость, км/ч, group). С группами можно конечно уйти в спираль нормализации и бесконечности справочников, но это уже зависит от задачи и рвения разработчика.

    Вроде бы это довольно классическая схема минимизирующая дублирование строковых атрибутов. Не знаю как амазоны справляются с такими задачами, но, судя по 60 полям у ТС, посидеть, собрать и структурировать как то все (в том числе и возможные в будущем) атрибуты, вполне реальная задача.
    5 окт 18, 21:19    [21696805]     Ответить | Цитировать Сообщить модератору
     Re: Структура базы данных.  [new]
    alexeyvg
    Member

    Откуда: Moscow
    Сообщений: 30768
    PizzaPizza
    ИМХО зависит от количества продуктов...

    У меня есть несколько источников данных (продукция), с каждого приходят разные наборы параметров (атрибуты) которые надо хранить. единственное ограничение, атрибуты все одного типа. У меня все int.

    Я храню
    продукты с описанием (id_product, name, etc) (1, экскаватор Э1, дорогой, красивый), (2, бульдозер БМ, дешевый, молодежный)
    все параметры продуктов в одной таблице (id_product, id_param_name, value) (1,100,60)
    наименования параметров в библиотеке (id_param_name, param_name)(100, скорость)

    то есть для любого продукта тут может быть любое количество атрибутов и никаких null

    Дальше удобно делать пивотом отчет по известному мне сету параметров или же делать группы параметров в библиотеке (id_param_name, param_name, id_group) и собирать запрос по ним. Опять же в библиотеку можно вынести особенности атрибутов (id_param_name, param_name, type, group) (100, скорость, км/ч, group). С группами можно конечно уйти в спираль нормализации и бесконечности справочников, но это уже зависит от задачи и рвения разработчика.

    Вроде бы это довольно классическая схема минимизирующая дублирование строковых атрибутов. Не знаю как амазоны справляются с такими задачами, но, судя по 60 полям у ТС, посидеть, собрать и структурировать как то все (в том числе и возможные в будущем) атрибуты, вполне реальная задача.
    У меня был такой вариант - сделать EAV для параметров, а потом для товаров, обладающих одинаковым набором параметров, автоматически создаются таблицы с значениями этих параметров, и далее всё хранится там.
    Выглядит громоздко, но зато обеспечивает высокую производительность.

    Но для ТС я такого не посоветую, не зная, нужно ли такое усложнение.

    И даже EAV - зачем это? Какой нибудь парикмахерской?
    10 лет у фирмы были продукты с 60 параметрами, потом появились продукты с 3мя, и ещё 10 лет ничего не поменяется. А потом фирма исчезнет, или все перейдут на нейронные компьютеры.

    И зачем бизнесу вкладывать бабло в изменение модели данных и приложений, что это им даст, какой навар? Удовлетворение программиста от "нормализации"?
    Или возможность добавить через 10 лет новый параметр одним нажатием кнопки? А эта возможность позволит сэкономить, уволив их единственного программиста? Если нет, то какой смысл делать одной кнопкой? Начальник распорядится - программист добавит параметр, без всяких EAV

    Я попытался дать рецепт, исходя из формулировок ТС, ИМХО не нужно ему никаких изменений модели данных, для их бизнес-процессов, нагрузок, объёмов, частоты изменений, сложности данных и т.п. Просто ждя некоторых типов использовать 3 поля, этого достаточно.
    5 окт 18, 21:58    [21696828]     Ответить | Цитировать Сообщить модератору
     Re: Структура базы данных.  [new]
    PizzaPizza
    Member

    Откуда:
    Сообщений: 309
    alexeyvg

    И даже EAV - зачем это? Какой нибудь парикмахерской?
    10 лет у фирмы были продукты с 60 параметрами, потом появились продукты с 3мя, и ещё 10 лет ничего не поменяется. А потом фирма исчезнет, или все перейдут на нейронные компьютеры.


    Ох скорее бы нейронные и все такое уже :)

    Думается мне, что реляционные бд ещё поживут, пока структурированные данные существуют, а вот бизнес столько не протянет.

    В целом я бы отталкивался от количества сущностей. Если это до миллионов строк продуктов, и никакой статистики и выборки условно раз в минуту, то жить и так можно и даже проще, тем более, что хранить, судя по всему, собираются почти битовые значения. Немного смущает, что возможно много дублирующих сущностей с, например, разницей в один атрибут. Но тут без специфики данных не понять.
    5 окт 18, 22:13    [21696831]     Ответить | Цитировать Сообщить модератору
    Все форумы / Microsoft SQL Server Ответить