| Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
| Все форумы / Microsoft SQL Server |
  |
||
 Структура базы данных.
|
|
|
vladka63 Member Откуда: Сообщений: 1689 |
Добрый день. Совет нужен, уважаемые коллеги. Суть в следующем: у сайта, в базе данных, есть таблица Product. В этой таблице около 60 полей. Реально, по товарам, в комбинациях задействовано около 40 полей. И из этой таблицы продукты выводятся на страницы сайта. Теперь возникла задача. Нужно добавить на сайт еще один вид продуктов. Но дело в том, что для этого вида продуктов будет нужно всего 3 поля из 60, остальные поля будут заполняться значениями по умолчанию (null, true, false)и в общем то, эти значения по умолчанию никогда не будут влиять на вывод нового продукта на страницу (в смысле функции). Т.е, просто чтобы запросы корректно обрабатывались и все. Вопрос: на ваш новый продукт помещать в имеющуюся таблицу или лучше создать новую таблицу с 3-я полями? Вопрос возник в связи с тем, что: а имеет ли смысл при каждом запросе обрабатывать 60 полей, если точно понятно, что выведет только 3.. Спасибо. |
| 5 окт 18, 08:53 [21695973] Ответить | Цитировать Сообщить модератору | |
| Re: Структура базы данных.
|
|
|
Щукина Анна Member Откуда: Сообщений: 1467 |
vladka63, а завтра появится продукт с пятью полями - ещё таблицу делать будете? а послезавтра нужно будет семь полей, затем десять. на каждый такой чих будете по таблице делать? Если уж и городить новые таблицы и есть возможность менять структуру базы и работающий с ней код, то лучше заняться нормализацией и перепроектировать всю базу по новой... |
| 5 окт 18, 08:58 [21695976] Ответить | Цитировать Сообщить модератору | |
| Re: Структура базы данных.
|
|||
|
vladka63 Member Откуда: Сообщений: 1689 |
Есть логика в вашем ответе, Анна. Бесспорно есть.. А завтра их будет 15.. Хорошо, а что бы вы посоветовали, если бы этого "завтра" не было. Т.е, точно известно - что единожды будет добавлено наименование с описанием в трех полях. |
||
| 5 окт 18, 09:02 [21695981] Ответить | Цитировать Сообщить модератору | |||
 Re: Структура базы данных.
|
|
|
Щукина Анна Member Откуда: Сообщений: 1467 |
vladka63, ещё раз, если в первый раз эта мысль была озвучена не достаточно ясно: заняться нормализацией базы. хотя бы до третьей нормальной формы |
| 5 окт 18, 09:11 [21695987] Ответить | Цитировать Сообщить модератору | |
| Re: Структура базы данных.
|
|||
|
alexeyvg Member Откуда: Moscow Сообщений: 31355 |
Если не стоит остро вопрос оптимизации хранения (например, там миллиарды записей), то лучше оставить всё в одной таблице. |
||
| 5 окт 18, 09:15 [21695989] Ответить | Цитировать Сообщить модератору | |||
| Re: Структура базы данных.
|
|||||
|
vladka63 Member Откуда: Сообщений: 1689 |
Спасибо, понял :-) |
||||
| 5 окт 18, 09:17 [21695993] Ответить | Цитировать Сообщить модератору | |||||
| Re: Структура базы данных.
|
|||
|
alexeyvg Member Откуда: Moscow Сообщений: 31355 |
Вот у нас есть продукция, там есть записи Экскаваторы и Бульдозеры У экскаваторов есть атрибут "объём ковша", у бульдозеров нет Вполне типичная ситуация для любой торговой фирмы, например. Только там 100500 типов товаров, а не два. Как следует поступить? Делать 2 таблицы? Делать EAV? Делать связанные сущности свойства экскаватора/бульдозера? ИМХО вполне нормальным является вариант, когда в таблицу запихивают все атрибуты, а заполняют подходящие, хотя, конечно, тут есть недостатки. |
||
| 5 окт 18, 09:21 [21695997] Ответить | Цитировать Сообщить модератору | |||
| Re: Структура базы данных.
|
|||
|
alexeyvg Member Откуда: Moscow Сообщений: 31355 |
Если для бизнеса это только "Продукция", то нужно делать одну таблицу. Или одну таблицу, + EAV для свойств. Если для бизнеса это разные по смыслу сущности, то не надо объединять их в одной таблице. Тогда стандартный подход - делать таблицу Продукция, и 2 подчинённых таблицы со связью 1-1, с специфическим набором атрибутов. Ну и отдельные решения для особых случаев - большая нагрузка, либо большой объём. |
||
| 5 окт 18, 09:30 [21696006] Ответить | Цитировать Сообщить модератору | |||
| Re: Структура базы данных.
|
|
|
Владимир Затуливетер Member Откуда: Сообщений: 427 |
Полностью согласен с alexeyvg. Лучше сделать в одной таблице иначе будет просто неудобно работать с этим данными. А хранение данных всегда можно оптимизировать. |
| 5 окт 18, 11:18 [21696118] Ответить | Цитировать Сообщить модератору | |
| Re: Структура базы данных.
|
|||
|
TaPaK Member Откуда: Kiev Сообщений: 6801 |
форум всё хуже и хуже.... EAV если нет понимания конечного масштабирования, или на 2 таблицы объект с основными для всех параметрами + таблица EAV к ней |
||
| 5 окт 18, 11:23 [21696123] Ответить | Цитировать Сообщить модератору | |||
| Re: Структура базы данных.
|
|
|
Владислав Колосов Member Откуда: Сообщений: 7757 |
alexeyvg, это делается путем создания таблицы, в которой хранятся пары типа "ключ-значение". |
| 5 окт 18, 11:57 [21696188] Ответить | Цитировать Сообщить модератору | |
| Re: Структура базы данных.
|
|||
|
TaPaK Member Откуда: Kiev Сообщений: 6801 |
он так и сказал EAV |
||
| 5 окт 18, 12:01 [21696199] Ответить | Цитировать Сообщить модератору | |||
| Re: Структура базы данных.
|
|||
|
256k Member Откуда: с.Торчилово, Псковская обл. Сообщений: 437 |
всегда или нет, еще вопрос, юзер не указал версию сервера |
||
| 5 окт 18, 13:05 [21696312] Ответить | Цитировать Сообщить модератору | |||
| Re: Структура базы данных.
|
|||||
|
PizzaPizza Member Откуда: Сообщений: 367 |
ИМХО зависит от количества продуктов... У меня есть несколько источников данных (продукция), с каждого приходят разные наборы параметров (атрибуты) которые надо хранить. единственное ограничение, атрибуты все одного типа. У меня все 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: Структура базы данных.
|
|||
|
alexeyvg Member Откуда: Moscow Сообщений: 31355 |
Выглядит громоздко, но зато обеспечивает высокую производительность. Но для ТС я такого не посоветую, не зная, нужно ли такое усложнение. И даже EAV - зачем это? Какой нибудь парикмахерской? 10 лет у фирмы были продукты с 60 параметрами, потом появились продукты с 3мя, и ещё 10 лет ничего не поменяется. А потом фирма исчезнет, или все перейдут на нейронные компьютеры. И зачем бизнесу вкладывать бабло в изменение модели данных и приложений, что это им даст, какой навар? Удовлетворение программиста от "нормализации"? Или возможность добавить через 10 лет новый параметр одним нажатием кнопки? А эта возможность позволит сэкономить, уволив их единственного программиста? Если нет, то какой смысл делать одной кнопкой? Начальник распорядится - программист добавит параметр, без всяких EAV Я попытался дать рецепт, исходя из формулировок ТС, ИМХО не нужно ему никаких изменений модели данных, для их бизнес-процессов, нагрузок, объёмов, частоты изменений, сложности данных и т.п. Просто ждя некоторых типов использовать 3 поля, этого достаточно. |
||
| 5 окт 18, 21:58 [21696828] Ответить | Цитировать Сообщить модератору | |||
| Re: Структура базы данных.
|
|||
|
PizzaPizza Member Откуда: Сообщений: 367 |
Ох скорее бы нейронные и все такое уже :) Думается мне, что реляционные бд ещё поживут, пока структурированные данные существуют, а вот бизнес столько не протянет. В целом я бы отталкивался от количества сущностей. Если это до миллионов строк продуктов, и никакой статистики и выборки условно раз в минуту, то жить и так можно и даже проще, тем более, что хранить, судя по всему, собираются почти битовые значения. Немного смущает, что возможно много дублирующих сущностей с, например, разницей в один атрибут. Но тут без специфики данных не понять. |
||
| 5 окт 18, 22:13 [21696831] Ответить | Цитировать Сообщить модератору | |||
| Все форумы / Microsoft SQL Server | |
|
x