Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.145.7.116] |
|
Данный раздел предназначается исключительно для обсуждения вопросов использования языка запросов SQL. Обсуждение общих вопросов, связанных с тематикой баз данных - обсуждаем в разделе "Базы данных: общие вопросы". Убедительная просьба - соблюдать "Правила форума" и не пренебрегать "Правильным оформлением своих тем". Прежде, чем создавать тему, имеет смысл заглянуть в раздел "Базы данных: FAQ", возможно там уже есть ответ. |
Страницы: (2) [1] 2 все ( Перейти к последнему сообщению ) |
Сообщ.
#1
,
|
|
|
ads
ad_id, description, user_id,.... 1, Продаю - срочно, 22 ad_setting_types ad_setting_type_id, value 1, цвет 2, кузов 3, кпп ad_setting_type_options option_id, ad_setting_type_id, value 1, 1, желтый 2, 1, красный 3, 1, зеленый 4, 2, хетчбек 5, 2, седан 6, 3, механика 7, 3, автомат 8, 3, вариатор таким образом мы можем описать зеленый хетчбек с механикой как ad_settings ad_id, option_id 1, 3 1, 4 1, 6 Рабочая схема, но столкнулся с проблемой когда пользователь заполняет customное поле типа пробег, цена, грузоподъемность. Как и куда сохранять данные? |
Сообщ.
#2
,
|
|
|
Заполнить в ту же таблицу где храняться ID машин? В основную в спец стоблцы.
Да и твой вариант модифицировать до ad_id, option, option_type не долго. option_type: rel\text\еще_что_то Интереснее лично мне во всем этом, это проблема скорости выборок. Как ты с этим справляешься? Записи с переменным количеством полей -- похожая тема, и такой же вопрос начиная с поста #8 |
Сообщ.
#3
,
|
|
|
Да ладно скорости... а представь себе отбор по нескольким критериям, но не всем, в совокупности, да с разным типом (=, <, >=, between, etc.)... это ж какой запрос получится!
|
Сообщ.
#4
,
|
|
|
Akina, на самом деле несмотря на то, что прошло почти 3 года с того моего обсуждения. Вопрос для меня остался интересным и нерешенным.
Просто я не вижу других вариантов. Что еще можно предложить для тех же авто (не говоря о том если необходимо хранить разные типы объектов)? Таблицу с сотней колонок? Добавлено Цитата Akina @ а представь себе отбор по нескольким критериям Ну да.. по джойну на каждый параметр. Только запрос строить какой угодно сложный автоматически можно, все упирается в скорость его исполнения. |
Сообщ.
#5
,
|
|
|
а если такой вариант ?
http://img707.imageshack.us/img707/3250/87734385.jpg |
Сообщ.
#6
,
|
||||||||||||||||||||||||||||||||
|
Получается лишнее условие.
Другая марка, и то что у тебя 3784 лишние строки. Тебе надо их связать, только ради того чтобы знать что это поле не требует зависимостей. Не очень логично. Добавлено Правильная структура на мой взляд такова. Автомобили
Параметры
Значения параметров
Связи
Добавлено Но выборки смертельные. |
Сообщ.
#7
,
|
||||||||||||||||||||||||||||||||
|
Цитата Pr0[)!9Y @ Получается лишнее условие. Другая марка, и то что у тебя 3784 лишние строки. Тебе надо их связать, только ради того чтобы знать что это поле не требует зависимостей. Не очень логично. Добавлено Правильная структура на мой взляд такова. Автомобили
Параметры
Значения параметров
Связи
Добавлено Но выборки смертельные. Если расставить индексы, все ок. Только, что тестировал, таблица settings во время проведения теста хранила в себе 2 500 000 строк. |
Сообщ.
#8
,
|
|
|
А условия, а поиск? Не верится мне в скорость.
|
Сообщ.
#9
,
|
|
|
Pr0[)!9Y
Спасибо. |
Сообщ.
#10
,
|
|
|
Цитата Pr0[)!9Y @ Правильная структура на мой взляд такова. ой мама ... У вас у автомобилей свойства постоянно меняются, была марка а стала мощность? В такие табицы надо вписывать, то что "дополнительно", а вот все туда абсолютно не нужно. |
Сообщ.
#11
,
|
|
|
Я посоветовал вписать изменяемые свойства в основную таблицу.
Цитата Pr0[)!9Y @ Человеку этот вариант не понравился, да и вообще плохо что поля будут в разных структурах храниться. Половина так, а половина так.Заполнить в ту же таблицу где храняться ID машин? В основную в спец стоблцы. Цитата SPM @ Причем тут изменение какое-либо?У вас у автомобилей свойства постоянно меняются, была марка а стала мощность? Не знаю как для топикстартера, но во втором посте я ссылку привел на мою тему. Как тогда хранить если у меня разные типы объектов? Раз уж темы пересекаются. |
Сообщ.
#12
,
|
|
|
Цитата Pr0[)!9Y @ Причем тут изменение какое-либо? А тогда зачем все эти "пляски"? Не проще ли все основные правметры держать вместе с сущностью? Топикстартер явно говорит о "авто объявления", а не о складе в гипермаркете. |
Сообщ.
#13
,
|
|
|
Цитата SPM @ Проще, лучше и быстрее. Не проще ли все основные правметры держать вместе с сущностью? |
Сообщ.
#14
,
|
|||||||||||||||||||||||||
|
Чего-то я не понимаю, зачем вообще делить параметры на основные и дополнительные.
Стоит либо забить все параметры в соотв. столбцы, либо в отдельную таблицу. Если в отдельную, то как-нить так: auto:
params:
Чего ещё выёживаться? Добавлено Если нужны всякие там диапазоны вхождений, варианты выбора и т.п., то тогда стоит добавить отдельную таблицу с вариантами выбора (`param_id`, `value_id`, `value_name`, `order`), а в основной хранить value_id. Есс-но в у параметра должно быть указание, что выбор осуществляется из отд. таблицы. Если-же это будет обрабатываться каким-нить пыхом, то можно завернуть их как-нить в одну строку и добавить в столбец таблицы параметров. В любом случае, это 2-3 таблицы, а не 4. |
Сообщ.
#15
,
|
|
|
Цитата Pr0[)!9Y @ Только запрос строить какой угодно сложный автоматически можно, все упирается в скорость его исполнения. Ограничение на сложность запроса (да и тривиально на его размер) всё-таки есть. Другое дело что до него долго брести - но когда-нить непременно упрёшься. |