Ну один пункт можете смело вычеркивать - это web-zona.
Я как то писал отзыв про его доску объявлений: Хочу предупредить возможных покупателей web-zona, но с биржей труда скорее всего тоже самое. Так что, что бы не терять время, нервыи деньги - лучше даже не смотрите в эту сторону. :)
Алексей Ганагин: Я это понимаю, но вы представляете насколько увеличится время запроса, если потребуется запросить значения из всех справочников, да если ещё это будет в табличном выводе, т.е. для несколько объявлений? Или вы знаете какой-то другой, быстрый способ?
topy: Предлагаю сделать в форме поиска некие изменения, которые сделают более удобный поиск:
1. Добавить в "Состояние" пункт "все кроме битых", или сделать multiple, чтобы можно было вибирать несколько вариантов.
2. Переименовать "Коробка" в трансмиссия ибо это более правильно. И тоже сделать multiple, т.к. вариатор по-сути тоже не механика, и например, если человек не хочет механику, то ему все равно что АКПП или вариатор, но если ему принципиально искать вариатор, то такая возможность у него останется. Да, кстати, коробка называется не "ручная" а механическая.
3. Сделать возможность выбирать валюту при добавлении и при поиске.
4. Добавить в "Производитель" пункт "Отечественные" и "Иномарки". Знаете, как на авто.ру - очень удобно отсеивать жигули :)
5. Развернуть году в селекте "Год до" чтобы от 2008 до 1970, а не 1970 до 2008... ИМХО более грамотно.
6. Посмотрите на авто.ру типы кузовов и добавьте себе недостающие.
7. В списке городов Москву и Спб вынести наверх, т.к. очень большой процент посещений идет оттуда (если у вас не региональная доска, конечно).
8. Сделать привод multiple, чтобы можно было выбрать передний и полный, например.
9. В идеале сделать чекбоксы для опций, как на авто.ру, чтобы можно было бы найти все машины с ГБО или с mp3-магнитолой...
Это так сказать идеальная форма поиска для меня, т.к. я ищу машины довольно часто.
С технической точки зрения в текущей версии сделать это невозможно.
Как можно и нужно сделать!
Сделать опять же справочники данных, что бы теже самые типы кузовов подставлялись не в шаблоне, а брались из справочника. Тогда в объявлении в поле с типом кузова будет хранится не слово varchar() а целое число - ссылка на справочник. Или же если подразумевается выбор нескольких пунктов как предлагается с приводом - то делать через таблицу связки. Данный подход позволяет сохранить целостность данных и легкость внесения новых данных. Но это конечно же ничтожно посравнению с производительностью при выборке по определенным условиям.
Сравните:
CarType
----------------
Id | Title
----------------
1 | Дизель
2 | Бензин
3 | Гибрид
----------------
Car
----------------
Id | CarTypeId | ...
----------------
1 | 1
2 | 1
3 | 3
........
----------------
или же как у Вас:
Car
----------------
Id | CarType | ...
----------------
1 | Дизель
2 | Дизель
3 | Бензин
........
----------------
В результате для выбора автомобилей с дизельным двигателем получаем:
1: SELECT * FROM car WHERE CarTypeId=1
2: SELECT * FROM car WHERE CarType='Дизель'
При поиске же дизельного переднеприводного автомобиля автомобиля с MP3 магнитолой, левым рулем и автоматической коробкой БД просто обалдеет.
Алексей Ганагин: Для объявления сохраняется излишняя информация, такая как название города — это сделано для ускорения вывода, представьте сколько времени экономится при табличном выводе.
Да ровно нисколько времени не экономится на этом!
Я не предлагаю при каждом обращении к объявлению дергать целиком все его значения из справочников, а сделать это "ленивой" выборкой - по мере обращения. Таким образом запрос на выбор значения по первичному ключу (да еще и в большинстве случаев из небольшой таблички), да еще если и с кешированием не затруднит и будет совершенно не заметной!
Я бы сделал примерно так:
class Car
{
protected $id = null;
protected $type = null;
protected $typeId = null;
....
public function getId() {
return $this->id;
}
public function getType() {
if (is_null($this->type)) {
$this->type = DbSQL::getTypeById($this->typeId);
}
return $this->type;
}
}
class CarType
{
protected $id = null;
protected $title = null;
....
public function getId() {
return $this->id;
}
public function getTitle() {
return $this->title;
}
}
///Таким образом получив из базы $car мы выводим:
echo $car->Id . ": " . $car->getType()->getTitle();
Так что есть еще над чем работать и работать, а номер этой версии лучше изменить с 1.2 на 0.1.2 🚬
Проект подойдет может быть только для какого нить небольшого сайта с посещаемостью ~100человек.
Иначе просто не удобно пользоваться и искать объявления.
При работе с сущностями - абсолютное отсутствие справочников, за исключением разве что городов, да и то мнимо...
`city_id` int(11) NOT NULL,
`city` varchar(255) NOT NULL,
...
`proizvoditel_id` int(11) NOT NULL,
`proizvoditel` varchar(255) NOT NULL,
...
`model_id` int(11) NOT NULL,
`model` varchar(255) NOT NULL,
Записывать в таблицу с объявлением название города - не продуктивная оптимизация, а накладные расходы. Все остальные же сущности пишутся в базу как есть текстом в отдельные поля или скопом (как "дополнительные опции" - видимо для облегчения вывода :) )и по ним же идет сравнение, к примеру, в форме редактирования.
`sostoyanie` varchar(9) NOT NULL,
`tip_kuzova` varchar(16) NOT NULL,
`toplivo` varchar(6) NOT NULL,
`korobka` varchar(11) NOT NULL,
`privod` varchar(8) NOT NULL,
`dopolnitelno` text NOT NULL,
`opcii` text NOT NULL,
Таким образом добавить новую опцию или еще какое значение в список довольно утомительное занятие.
Про легкость смены дизайна я бы тоже так громко не заявлял. Отсутствие шаблонов и необходимости правки PHP файлов для смены внешнего вида отнюдь не самое приятное занятие.
Ну и немешалобы добавить немного интерактивности - загрузки моделей по выбранной марке аяксом. А так на странице создания объявления постоянно генерится лишний JavaScript довольно внушительного объема.
ndix: А корп. емаил зачем нужны ?
Вопрос только с теми компаниями у которых нет корп.email.
Идея высылать запрос на присоединение к компании на корпоративные email хороша и поидее должна сработать при увольнении сотрудника, но опять же почты может и не быть корпоративной, тем более учитывая мою специфику (город в МО) и нет никакой гарантии что это не будет какой нить другой личный ящик пользователя.
Поэтому думаю оптимальным было бы не еще один скрытый адрес почты, а просто вопрос-ответ.
В принципе можно объединить эти обе функции... Присоединиться к компании можно если знать ответ на вопрос, заданный при создании компании, а если не знаешь - то отправить заявку на присоединение создателю.
Это работает! Но если file.php был указан для примера, то необходимо уточнить что должно быть
-K- добавил 03.01.2009 в 22:04
Чето не сообразил сразу, если просто все / заменить на _ то:
и разбирать адрес с помощью PHP. Ну или чего у вас там вместо него.
Реализовать такое на стороне Apache тоже можно но это слишком сложно и ресурсоемко по сравнению даже с php
Ничего сложного и ресурсоемкого, пример выше. На PHP разбирать 100% выйдет дороже и сложнее.
Ну один пункт можете смело вычеркивать - это web-zona.
Я как то писал отзыв про его доску объявлений: Хочу предупредить возможных покупателей web-zona, но с биржей труда скорее всего тоже самое. Так что, что бы не терять время, нервыи деньги - лучше даже не смотрите в эту сторону. :)
Вот сканер неплохой XSpider, есть демо версия с неплохим функционалом:
http://www.ptsecurity.ru/xs7download.asp
Попробуй Eclipse, во первых бесплатный и ИМХО удобней на много http://www.eclipse.org/pdt/
Я это понимаю, но вы представляете насколько увеличится время запроса, если потребуется запросить значения из всех справочников, да если ещё это будет в табличном выводе, т.е. для несколько объявлений? Или вы знаете какой-то другой, быстрый способ?
Вот вам для начала почитать: Основы проектирования реляционных баз данных и Отложенная инициализация
Я не предлагаю для выборки на вывод джоинить с ней сразу все таблицы со справочниками, а получать их при необходимости (см. мой пост выше).
Предлагаю сделать в форме поиска некие изменения, которые сделают более удобный поиск:
1. Добавить в "Состояние" пункт "все кроме битых", или сделать multiple, чтобы можно было вибирать несколько вариантов.
2. Переименовать "Коробка" в трансмиссия ибо это более правильно. И тоже сделать multiple, т.к. вариатор по-сути тоже не механика, и например, если человек не хочет механику, то ему все равно что АКПП или вариатор, но если ему принципиально искать вариатор, то такая возможность у него останется. Да, кстати, коробка называется не "ручная" а механическая.
3. Сделать возможность выбирать валюту при добавлении и при поиске.
4. Добавить в "Производитель" пункт "Отечественные" и "Иномарки". Знаете, как на авто.ру - очень удобно отсеивать жигули :)
5. Развернуть году в селекте "Год до" чтобы от 2008 до 1970, а не 1970 до 2008... ИМХО более грамотно.
6. Посмотрите на авто.ру типы кузовов и добавьте себе недостающие.
7. В списке городов Москву и Спб вынести наверх, т.к. очень большой процент посещений идет оттуда (если у вас не региональная доска, конечно).
8. Сделать привод multiple, чтобы можно было выбрать передний и полный, например.
9. В идеале сделать чекбоксы для опций, как на авто.ру, чтобы можно было бы найти все машины с ГБО или с mp3-магнитолой...
Это так сказать идеальная форма поиска для меня, т.к. я ищу машины довольно часто.
С технической точки зрения в текущей версии сделать это невозможно.
Как можно и нужно сделать!
Сделать опять же справочники данных, что бы теже самые типы кузовов подставлялись не в шаблоне, а брались из справочника. Тогда в объявлении в поле с типом кузова будет хранится не слово varchar() а целое число - ссылка на справочник. Или же если подразумевается выбор нескольких пунктов как предлагается с приводом - то делать через таблицу связки. Данный подход позволяет сохранить целостность данных и легкость внесения новых данных. Но это конечно же ничтожно посравнению с производительностью при выборке по определенным условиям.
Сравните:
или же как у Вас:
В результате для выбора автомобилей с дизельным двигателем получаем:
1: SELECT * FROM car WHERE CarTypeId=1
2: SELECT * FROM car WHERE CarType='Дизель'
При поиске же дизельного переднеприводного автомобиля автомобиля с MP3 магнитолой, левым рулем и автоматической коробкой БД просто обалдеет.
Для объявления сохраняется излишняя информация, такая как название города — это сделано для ускорения вывода, представьте сколько времени экономится при табличном выводе.
Да ровно нисколько времени не экономится на этом!
Я не предлагаю при каждом обращении к объявлению дергать целиком все его значения из справочников, а сделать это "ленивой" выборкой - по мере обращения. Таким образом запрос на выбор значения по первичному ключу (да еще и в большинстве случаев из небольшой таблички), да еще если и с кешированием не затруднит и будет совершенно не заметной!
Я бы сделал примерно так:
Так что есть еще над чем работать и работать, а номер этой версии лучше изменить с 1.2 на 0.1.2 🚬
Может проще регэкспом, как мускле сразу не скажу, но можно выбрать изменить и проапдейтить.
Регулярка вот такая:
$tel = preg_replace("/^.*?(\([^ ]*?[ ].*?)[ ].*$/i", "\\1", $tel);
Проект подойдет может быть только для какого нить небольшого сайта с посещаемостью ~100человек.
Иначе просто не удобно пользоваться и искать объявления.
При работе с сущностями - абсолютное отсутствие справочников, за исключением разве что городов, да и то мнимо...
Записывать в таблицу с объявлением название города - не продуктивная оптимизация, а накладные расходы. Все остальные же сущности пишутся в базу как есть текстом в отдельные поля или скопом (как "дополнительные опции" - видимо для облегчения вывода :) )и по ним же идет сравнение, к примеру, в форме редактирования.
Таким образом добавить новую опцию или еще какое значение в список довольно утомительное занятие.
Про легкость смены дизайна я бы тоже так громко не заявлял. Отсутствие шаблонов и необходимости правки PHP файлов для смены внешнего вида отнюдь не самое приятное занятие.
Ну и немешалобы добавить немного интерактивности - загрузки моделей по выбранной марке аяксом. А так на странице создания объявления постоянно генерится лишний JavaScript довольно внушительного объема.
А корп. емаил зачем нужны ?
Вопрос только с теми компаниями у которых нет корп.email.
Идея высылать запрос на присоединение к компании на корпоративные email хороша и поидее должна сработать при увольнении сотрудника, но опять же почты может и не быть корпоративной, тем более учитывая мою специфику (город в МО) и нет никакой гарантии что это не будет какой нить другой личный ящик пользователя.
Поэтому думаю оптимальным было бы не еще один скрытый адрес почты, а просто вопрос-ответ.
Спасибо за мнения.
В принципе можно объединить эти обе функции... Присоединиться к компании можно если знать ответ на вопрос, заданный при создании компании, а если не знаешь - то отправить заявку на присоединение создателю.