Универсальное хранение данных с общими и разными полями

[Фанат]

не на каждый.
а вот на вопрос "давайте мне варианты, а их буду хаять" - в самый раз. Пиши авторам.

Дюбуа Mysql

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

Создавать отдельную таблицу для каждого товара - головотяпство в любом случае.
Не меньшее головотяпство - думать, что созданием объекта ты решишь все проблемы.
Не решишь. Если у тебя нет под новые свойства никакой инфраструктуры, то ты и использовать их СРЕДСТВАМИ БД не сможешь. поскольку наша старая добрая реляционная модель предусамтривает именно предварительное структурирование данных.

Отстать от нас, убогих, снашим мускулем, и обрати свой взор в сторону бинарных деревьев.
А ещё лучше - в сторону XML. Вот это - идеальный сормат под твои требования.

 

[440hz]

Re: Универсальное хранение данных с общими и разными полями

Автор оригинала: FiW
Кто что может предложить по данной теме?

написать над SQL базой классы с наследованием и экземпляры. Делал такое. Укладывается в 3 таблицы классов + 3 таблицы экземпляров + 1 дерево.

 

[FiW]

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

 

[Фанат]

ну вот.
я был прав.
тебе прелдложили решение, отвечающее на 100% твоим фантазиям.
а ты его даже рассматривать не хочешь.
однако я буду последовательным.
уговаривать тебя - много чести.

 

[FiW]

Фанат
вот тут ты ошибся абсолютно (как всегда?), с 440Hz я уже связался, как раз обсуждаем )))

 

[Фанат]

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

 

[svetasmirnova]

FiW
Меня прикалывает такая манера общения. Начать в публичном форуме, законыить лично в асе

-~{}~ 18.09.05 14:45:

Ну и чтобы всем, с кем лично не связались, было понятно о чём речь перевожу решение FiW на человекопонятный язык.
Имеется n таблиц.
1-я основная:
id main_feature1 main_feature2
n-1 дополнительных. Количество определяется типом данных
id feature_name feature

Т.е. join-ов будет ограниченное количество.

По хорошему надо бы ещё создать табличку типа:
feature_name feature_name_id

Но FiW о такой не упоминал

 

[440hz]

Автор оригинала: svetasmirnova
FiW
Меня прикалывает такая манера общения. Начать в публичном форуме, законыить лично в асе

да не вопрос.

www.art.440hz.spb.ru/adm/
test
test

www.art.440hz.spb.ru/source.tar.gz

 

[FiW]

svetasmirnova
ну на самом деле там можно еще много чего создать, я просто старался максимально упростить...

ps: а в асю полез, дабы не переводить это все в оффтопик, а прийти к взаимопониманию

pss: сейчас разбираюсь с решением от 440hz... помойму это то что надо...

 

[alexhemp]

FiW

Ваше "решение" - на уровне первого курса института. Почтитайте про нормализацию данных, ее в теории СУБД читают обычно на втором курсе.
После этого приходите, поговорим дальше.
А сейчас просто бесполезно.

 

[FiW]

alexhemp
а я разве говорил что оно лучшее? я лишь написал, что остановлюсь пока на этом... а другого пока что никто и не предложил (кроме 440hz)

ps: кстати, использование "фильтра" в php тянет наверное, как минимум курс на пятый, а то и на десертацию!

 

[alexhemp]

FiW

Я тебе предложил удобный и универсальный способ. Более того любые "фильтры" пишутся в ОДИН запрос даже в MySQL 3.x.

Работает - быстро, если создать соотв. запросу индексы. Потрудись поискать на форуме топики, посвященные хранению параметров товаров.

Вот отличный пример правильного проектирования базы
http://phpclub.ru/talk/showthread.php?s=&threadid=65869

 

[FiW]

alexhemp
Посмотрел твою ссылку (смотрел ее и до этого), перечитал снова (дважды) и так и непонял как "фильтрация" (или подбор по параметрам) может помочь в транспонировании?

 

[alexhemp]

FiW

Да ничем. Транспонирование тебе просто НЕ НУЖНО.
Это отностится не к выборке данных - а к их ПРЕДСТАВЛЕНИЮ НА ЭКРАНЕ.

Выбирай запросом СТРОКИ. Показывай НА ЭКРАНЕ - СТОЛБЦЫ.
Зачем тебе именно так выбирать (теряя между прочим информацию о том какое значение относится к какому атрибуту) - остается для всех загадкой.

Фильтр - это я к тому, что любой фильтр реализуется без транспонирования средствами SQL (не примитивным условием конечно, но реализуется без проблем).

Ответь на один вопрос - зачем КОНЕКРЕТНО тебе нужно получать результат именно в том виде, что ты написал.

Чем КОНЕКРЕТНО тебя не устраивет рекордсет

object_id, attr_id, value

 

[FiW]

alexhemp
транспонирования мне затем, чтобы не прокачивать лишние данные.

проблема потери информации о соответсвии атрибутов/значений решается добавление еще одной таблицы

про фильтры - абсолютно согласен.

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

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

 

[alexhemp]

FiW

Что значит "не прокачивать"? Ты сколько записей отображаешь за раз? Миллион или миллиард?
На 10-20-50-100 записях разницы видно не будет.

Еще раз повторю - ты можешь сделать такое представление рекордсета как ты описал выше только плохо спроектировав базу. Если ты ее спроектируешь хорошо, придется для такого вывода написать 2 строки PHP кода.
Все равно тебе в цикле записи перебирать, 2 строки не будут "лишние".

 

[FiW]

alexhemp
если оттталкиваться от такой логики (На 10-20-50-100 записях разницы видно не будет), то почему тогда не делать транспонирования?

 

[alexhemp]

FiW

Рассказываю последний раз:

Используя по таблице на каждый тип объектов ты добавляешь себе на порядки больше работы нежели написав 2 строки кода для вывода атрибутов объектов в строку.

Ты получаешь очень мнимое "удобство" и проигрываешь в универсальности и как следствие будешь писать больше кода и совершать больше ошибок.



Для проверки нарисуй на бумаге таблицу где запиши

1. Предполагаемая операция
2. Необходимые действия для варианта с отдельной таблицей на объект
3. Необходимые действия для варианта со списком атрибутов.

Так вот трудоемкость (не скорость выполнения) будут в первом случае выше, местами значительно.

Хозяин - барин, делай как знаешь я устал тебе объяснять очевидные вещи.

 

[FiW]

alexhemp
да не воспринимай ты все так в штыки

я не хочу сказать что твой метод плох. нет. просто это еще один метод решения (и это хорошо).

логику формирования запроса я все равно хотел на класс возложить. поэтому на описание кода (в верхних классах) это не сказывается...

ес-но я прекрасно понимаю, что если не получиться сделать все так как хочется, то от транспонирования я откажусь

ps: цель данных дебатов, не доказать свою правоту, а найти "изящное" решение...

 

[alexhemp]

FiW
У тебя похоже дебаты ради дебатов - не там ты ищешь изящность. У тебя данные - не нормализованы. В соотв. с теорией СУБД ждут тебя в дальнейшем большие трудности с их обработкой.