Что делать если нужны свойства на русском из БД?

Question

[survivor2005]

Всем здрасти. Хочу уточнить правильно ли я понимаю.
Пытаюсь делать интернет магазин. Есть у меня страница категорий товаров, например ноутбуки, телефоны и т д.
Есть страница карточек товаров которые соответствуют выбранной категории. И есть страница самого товара, его полное описание. Допустим возьмем ноутбук. В базе хранятся свойства в виде ключ=значение. Например: name = Asus Notebook, type=ультрабук, и т д. Но мне на странице товара надо вывести ключи на русском. Типа Название: Asus Notebook, тип: ультрабук, тип матрицы: IPS и т д.
Правильно ли я понимаю, что мне надо создать таблицу всех свойств типа name=название, type=тип, drive_value=объем носителя и т д. И затем делать join тиблиц? Или я не верно мыслю? Спасибо

Comments

[Дмитрий]

Зачем это делать в бд, делайте это в пхп

[survivor2005]

Дмитрий, А где это делать? В шаблоне? Или в классе? Я создаю класс на каждый вид товра типа class laptop. Задаю ему свойства такие же как в бд затем делаю выборку и на выходе у меня объект у которого ключ и значение такое же как в бд. То бишь я пытаюсь писать на ооп, но не знаю куда я воткну значения на русском.

[survivor2005]

Дмитрий, В шаблоне нельзя так как у него будут меняться свойства в зависимости от товара и они разные у всех

[Дмитрий]

survivor2005, ну код покажите, обычно переводы делают в шаблонах, ну или в моделях, это может быть не обязательно русский

[survivor2005]

Дмитрий, согласен с вами, я постараюсь сделать это в моделях, если не получится я пришлю код, надеюсь что то да решим тут. Спасибо

[survivor2005]

Дмитрий, А может перечислить все свойства в шаблоне, а если типа у товара нет такого свойства то не показывать его?

Answer 1

[eRKa]

Человеческие названия обычно уже делают на клиенте, по типу
<label>Тип:{{entity.type}}</label>
В базе редко хранят, что-то, что не меняется. Имена Ваших ключей навряд ли изменятся, а данные будут меняться постоянно.

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

Comments

[survivor2005]

Спасибо, я согласен, да действительно ключи будут меняться, то бишь допустим у чайника другие свойства нежели у ноутбука, потому собственно и спросил. Но исходя из ответов я постараюсь сделать это в бэке а не в бд. Что б не усложнять.

[eRKa]

survivor2005, это плохой вариант делать такое на бэке. Этот хардкор приведет к тому, что если displayName поменяется, то придется пересобирать проект и соответственно перевыкладывать со всеми вытекающими. В реальных проектах так никто делать не будет. Изменить через админку поле в бд проще, остальное автоматом подтянется.

[survivor2005]

eRKa, а displayName это что имелось в виду? Логичнее конечно сделать в бд список и джойнить. Тогда как я понял список этот будет состоять из свойств всех возможных товаров, если появится новая категория типа пылесосы то мне вручную надо дополнить список свойств которые будут у пылесоса, например мощность всасывания. Верно я понимаю?
А может перечислить все свойства в шаблоне, а если типа у товара нет такого свойства то не показывать его? Но это придется вечно лазить и вручную добавлять(

[eRKa]

survivor2005, displayName - отображаемое имя, так обычно именуется поле, где лежат значения для отображения клиенту.

Ваша схема будет примерно такой:

Products
id code displayName
1 tvset телевизор
2 kettle чайник

ProductProperties
id code displayName
1 size Размер
2 capacity Объем
3 power Мощность

PropertyRelations
productId propertyId
1 1
1 3
2 2
2 3

Здесь описано только одно вложение, как если бы был объект

TvSet {
  id,
  name,
  size,
  power
}

Но таким же способом можно добавить вложения и сделать как если бы объект был таким

TvSet {
  id,
  name,
  size,
  power,
  value: {
    price,
    discont
  },
  store: {
    ...
  }
}

Плюс такого подхода, что всегда можно добавить новое поле для объекта, расширить его как горизонтально, так и вертикально, без накатывания миграций, как если бы вам пришлось добавлять новый столбец в таблицу. Т.е. предполагаемые столбцы таблицы Вы храните как записи в отдельной таблице и просто связываете их с нужными объектами. Этот вариант имеет место на больших данных, которые часто изменяют свою форму.

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