Доброго времени суток!

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

Буду премного благодарен за инвайт, плюсану где только можно, если это конечно важно )

Можно выслать сюда:

alexandr.novitskiy[собака]gmail.com

skype - alexandr.novitskiy

инвайт чтобы ты задал вопрос? лол

А как же эксперты пг?

  Какой хабр лол, ты на элитном форуме среди экспертов по всем вопросам. Спрашивай.

А для чего еще, по-твоему, нужно избавиться от read only статуса на хабре ?

Суть проблемы такова:

В данный момент дописываю интернет магазин (компьютеры, комплектующие, портативные компы и тд).

К вопросу продумывания структуры базы подошел не совсем основательно, т.к. это первый более ни менее большой проект.
На начальном этапе, пока в базу добавлялись одни ноутбуки, нетбуки и тд, казалось бы, все нормально. Но вот дальшей встал вопрос о добавлении комплектухи и подобных товаров, т.к. у ноутбуков и им подобным кол-во аттрибутов (полей в таблице) ~24 + у каждого вида комплектующих еще по 5-6 уникальных для каждого вида аттрибутов, т.е. в процессе таблица должна расти в ширину, вроде и терпимо, но:

В поисках решения проблемы я отправился в интернеты. Ну и собственно для себя выделил два основных способа построения базы:

1) Single Table Inheritance (STI) - данная структура предполагает собой ОДНУ таблицу для всех товаров всех видов и, как я и предполагал, она будет рости в ширину и большинство полей в ней будет NULL-евыми. Вроде бы и кол-во товаров не должно превышать 5-6 тысяч ( по предварительным прогнозам ) т.е. таблица с примерно 40-50 полями и 5000-6000 строками без проблем будет возвращать нужные значения в считанные мгновения. И таки да, такая структура является реляционной БД, что для меня лично было откровением.

Тут в "админке" при добавлении товара в большую таблицу я просто указываю какие поля заполнять, остальные автоматом становятся NULL.

2)Entity-Attribute-Value (EAV) - предполагает собой разбиение товаров на три таблицы:

- Entity - Таблица, где хранится инфо о ВСЕХ товарах, но в виде 4-5 основных столбцов (одинаковых для всех). Таких как: id, навание, цена, производитель и тд.

-Attribute- хранит в себе весь список аттрибутов для каждого вида товара в виде (id_attribute, attr_value) т.е. получается довольно таки длинная таблица, как я понял. Если, допустим, будет 1000 ноутбуков по 15 уникальных параметров - это 15000 строк ( не так уж и много, но что есть то есть)

-Value-  таблица, которая связывает Entity и Attribute внешними ключами, пары вида (id_product, id_attribute) т.е. размер ее будет чуть больше таблицы Attribute.

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

-Запросы будут ОЧЕНЬ(как по мне) большие. Чтобы вывести карточку товара нужно будет нехило натыкать INNER JOINов

-Сложность структуры, а в следствии и путаница возникает по части движка (оный пишу на PHP), опять все переделывать и тд.

-И вообще: стоит ли игра свеч ? При таком количестве товаров стоит ли извращаться таким образом ?

Вот собственно что я хотел сказать и что спросить у умов программирования)

Спасибо за внимание!

вполне можешь обойтись форумами sql.ru

регистрация там свободная

/summon alaron 

надо поправить орфографию и пунктуацию у nevermindlol.

Я же просто попросил дельный совет или небольшую помощ, исходя из Ваших же советов.

Смысл сообщения, вроде бы, должен быть понятен всем грамотным (и не только) людям. Не вижу смысла придираться к моим знаниям русского языка, т.к. это не совсем уместно, да и я не особо заморачивался по этому поводу спустя 10 минут после пробуждения.

  Оправдываются только слабаки. Ты слабак.

Да не вопрос.

Только вот от тебя уже 2 сообщения в теме и ни одного ПО теме.. или хотя бы близко к теме.

Не находишь это странным ?

  Создав серьёзную тему в обители зла... мне правда интересно на что ты рассчитывал?

Я - нет. Очевидно, толковый человек в узкой теме заглядывает на пг, а тем более в Обитель, крайне редко, не жди ответа здесь. Впрочем, это не совсем так - дельный совет Василий тебе уже дал.

Я думал среди людей ездящих на авто бизнес-класса и покупающих часы за 100.000 у.е и тд. найдется пара-тройка быдло-кодеров, которые помогли бы с инвайтом на хабр ( помочь напрямую с решением проблемы - штука явно запредельная).

Не нашел другого более ни менее адекватного места тут для такого рода вопроса.

Какой смысл писать сюда экспертам(??) по части ББ, уровня игрового форума, которые вряд ли смогут растолковать разницу между соевым протеином, изолятом, казеином и гидролизатом. Загадка.

Все что я увидел в разделе IT  - это темы а-ля: "помогите выбрать ноутбук/телефо"н, "помогите с чего лучше начать программировать и прочий мусор". Разделы "Железо" и "Софт" тоже особо доверия не внушили.

Иногда читаю этот раздел (Обитель) есть вполне нормальные темы, большинство людей заглядывает именно сюда, а не в ИТ. Да и, повторюсь, я не просил напрямую помощи по проектировке БД тут, я просто попросил инвайт на хабр. Есть же разница.

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

Если все сделать правильно, то останется только следить за наполнением, качеством и актуальностью данных.

Спасибо за то, что откликнулся!

На данный момент я пытаюсь реализовать что-то вроде:

Есть таблица с видами основных характеристик: types (id,title)

есть таблица, где хранятся значения этих характеристик: type_list(id,id_type,value)

и в таблице товаров ( да, она будет одна для всех ) в поля этих характеристик будут вноситься внешние ключи из таблицы type_list

Эта идея пришла пару часов назад, сейчас пишу код для примерного видения её в деле, может прокомментируешь как-то такой способ ? У меня какие-то неоднозначные чувства по этому поводу.

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

Выясни какого рода вообще запросы могут быть с каждой формы (от вывода списка товаров с разными полями, до какой-нибудь печати-).

Структура вполне логичная, если я правильно понял, что это нечто типа:

1 | Ноутбуки

2 | Нетбуки

__________

1 | 1 | Ноутбуки

2 | 1 | Комплектующие   -- для ремонта и т.п.

3 | 1 | Аксесуары
4 | 2 | Нетбуки

5 | 2 | Комплектующие

^

ProductTypeID

...

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

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

Спасибо!

Просто уже 2 дня засыпаю и просыпаюсь с этими мыслями в голове )

сижу на работе, вот сегондя вечером уже буду начинать что-то делать.. пока что остановился на "проапгрейденом" предиущем варианте:

1 таблица - goods (id,title,brand,price,img..) хранит в себе инфо о ВСЕХ товарах, но только основные поля, которые есть у каждого товара.

2 таблица - notebooks(id, id_good, param1,param2,param3) хранит в себе инфо о ноутбуках, для каждоого ноута - одна строка с id_good - внешним ключем таблицы goods;

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

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