Алексей Ганагин

Рейтинг
6
Регистрация
22.11.2008
resad93:
Спасибо за скрипт.
Ест одна проблемка. Скажите пожалуйста , у меня скрипт в localhost (apache) .
Как указать
-Адрес сайта ( $global['url'] = ''; ),
-Директория где будет расположен скрипт ( $global['directory'] = ' ' ) и
-Абсолютный путь до скрипта ( $global['script_path'] = ' ).

$global['url'] = 'localhost';

$global['directory'] = ''; // Оставляем пустой

$global['script_path'] = ''; // Тут физический путь до файлов скрипта

Алексей Ганагин добавил 05.02.2009 в 16:31

YugForum:
Поддерживаю, CMS давно требует такого модуля, а скрипт ТС - очень хорош, хотелось бы видеть интеграцию...

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

Новая версия уже готова, сейчас идёт тестирование.

dimmmid, ВашХостинг — проще всего будет установить скрипт в директорию, например /auto и сделать дизайн такой-же как у основного сайта.

Я считаю, что интеграция с CMS оправдана только в том случае, когда нужно использовать общие таблицы в БД, например users, city и т.д. или когда требуется единая авторизация пользователей.

ВашХостинг:
Алексей Ганагин, Вы почему-то не отвечаете на мой вопрос :) Можно ли этот скрипт интегрировать в CMS DLE?

Действительно, не заметил ваш вопрос. Объясните, что вы понимаете под "интеграцией", т.е. что именно вы хотите получить?

Следующая версия будет в январе, в этом году уже никак не успеваю.

Всех с наступающим 2009 годом!

Да, новая версия в разработке.

topy:
Я думаю при грамотном кешировании это можно сделать, ведь работают же другие сайты с большой нагрузкой.
И тем более в чем проблема-то???
Вы в форме поиска пишете value в select из базы, и там и ищите

SELECT * FROM car WHERE CarType='2' && engine=3 && color=5;

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

Ну в общем решение есть, надо только подумать как это более грамотно сделать.
upd: посмотрите как на авто.ру сделано.... у них поисковая форма передает в get-запросе все поисковые значения.... Очень удобно! Вы же не видите там нигде value='инжектор', там идет engine_key=1 и так по всем справочникам....

Я согласен с вами, про выборку по ключам, а не по значениям, это действительно быстрее и это будет. Но я настаиваю на том, что справочники нужно держать в массивах (т.е. сразу в оперативной памяти, без запросов к базе), это наиболее экономный вариант в данной ситуации. Кэширование которое вы предлагаете использовать — будет делать тоже самое, только потребует большего объёма памяти для работы.

topy:
А ведь -K- абсолютно прав!!!
Я просто не смотрел исходники и не видел того что там твориться. Конечно же все нужно хранить в таблицах, делать справочники и пр.
Это потом облегчает администрирование и улучшает быстродействие при бОльших нагрузках.
Алексей Ганагин, вы можете столкнуться с серьезными проблемами при запросах, подобных этому:

SELECT * FROM car WHERE CarType='Дизель';

и скажем мягко - это не есть правильное использование базы данных.
А если вы что-то собираетесь хранить в массивах (отдельно от таблиц), значит у вас немного не верное представление о базах данных и о том зачем они нужны.
(они как раз и нужны чтобы хранить структурированную информацию, и делают они это ВЕЛИКОЛЕПНО, а вы про какие-то массивы).......
Мы вам тут подсказываем наиболее правильное решение, а дальше уж решайте сами....

Я это понимаю, но вы представляете насколько увеличится время запроса, если потребуется запросить значения из всех справочников, да если ещё это будет в табличном выводе, т.е. для несколько объявлений? Или вы знаете какой-то другой, быстрый способ?

-K-:
Сделать опять же справочники данных, что бы теже самые типы кузовов подставлялись не в шаблоне, а брались из справочника. Тогда в объявлении в поле с типом кузова будет хранится не слово varchar() а целое число - ссылка на справочник. Или же если подразумевается выбор нескольких пунктов как предлагается с приводом - то делать через таблицу связки. Данный подход позволяет сохранить целостность данных и легкость внесения новых данных. Но это конечно же ничтожно посравнению с производительностью при выборке по определенным условиям.

Про справочники это понятно и они действительно будут, но не в таблицах, а в массивах, т.к. делать справочник с двумя-тремя значениями не оптимально, да и при таком большом объёме справочников — будут катастрофически медленные запросы.

-K-:
При работе с сущностями - абсолютное отсутствие справочников, за исключением разве что городов, да и то мнимо....

Для объявления сохраняется излишняя информация, такая как название города — это сделано для ускорения вывода, представьте сколько времени экономится при табличном выводе.

123
Всего: 29