hwt0Здравствуйте, помогите понять, как правильно сделать схему базы данных.
это всю жизнь было так:
таблица товаров (goods) + таблица названий свойств (prop_name) + таблица свойств товаров (props2goods)
вы просто в товар набираете нужные свойства + их кол-во

hwt0Правильно ли я понял идею с наследованием ?

нет
Printers, Mobile и Televisor это 1 таблица, таблица названий свойств - `prop_name`
она содержит вообще все возможные св-ва в магазине
содержимое этих свойств в каждом товаре это другая таблица - `props2goods`

Кот Матроскинtip78пропущено...


нет
Printers, Mobile и Televisor это 1 таблица, таблица названий свойств - `prop_name`
она содержит вообще все возможные св-ва в магазине
содержимое этих свойств в каждом товаре это другая таблица - `props2goods`

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

Кот Матроскинtip78пропущено...

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

Кот Матроскинmini.weblabотношения между таблицами по-моему неверны

Отношения на схеме - да, отношения между goods и printers/mobiles/... должны быть 1:0..1, а не 1:n. Но это, видимо, просто ошибка в схеме, написал-то ТС правильно
Таблица goods имеет отношения с таблицей printers (idgoods - idprinters) оба они первичные ключи.

tip78 неправильно разбивать каждую группу товаров по отдельным таблицам свойств
у него принтеры это одна таблица свойств, мобильники - другая, итд
Еще раз - это называется "наследование типов". Погуглите.
ну вообще-то называется "наследование таблиц" и... вы сами то вникали?
именно это я и называю "неправильно"
вы выбрали чуть меньший размер БД в ущерб скорости
хотя у ТС магазин и для таких задач важнее скорость
(строго говоря, скорость важнее практически для любых задач, разве что бэкапам пофиг, а размер там дело десятое)
вы бы, на досуге, редис для себя открыли (ваша очередь гуглить), подивились бы, как там дела обстоят с соотношением размер/скорость
но там сжатие например есть, оно чуть спасает
хотя и не особо надо
зато 100к запросов в секунду
расскажите им про наследования...

кстати, вот ссылка от IBM
авторFigure 4. Mapping each class to its own data entity
The main advantage of this approach is that it conforms best to object-oriented concepts. It supports polymorphism very well as you merely have records in the appropriate tables for each role that an object might have. It is also very easy to modify superclasses and add new subclasses because you merely need to modify or add one table. There are several disadvantages to this approach. First, there are many tables in the database -- one for every class, in fact (plus tables to maintain relationships). Second, it takes longer to read and write data using this technique because you have to access multiple tables. This problem can be alleviated if you organize your database intelligently by putting each table within a class hierarchy on different physical disk-drive platters (this assumes that each of the disk-drive heads operate independently). Third, ad hoc reporting on your database is difficult, unless you add views to simulate the desired tables.
блабла полиморфизм, нафиг не нужный
читаем про минусы (disadvantages)
автор Second, it takes longer to read and write data using this technique because you have to access multiple tables.