Города в три уровня: Страна, Регион, Город

[DenVeroid]

Города в три уровня: Страна, Регион, Город

вот решил на сайте для своего движка сделать Страна, Регион, Города

посоветуйте как лутьше это дело организовать, я так понимаю структуру можно организовать как "один ко многим" в даном случии три таблици country, region, city

также имеется другая таблица, для недвижимости "estate", как правельно сделать хранение в даной таблице города, ечли нам потребуется в дальнейшем делать выборку отдельно по Городам, по Региону, по Стране

к примеру можно в таблице недвижимость создать три поля (int) "country", "region", "city"
где при добавлении или редактировании указывать соответсвующий ID

или создать одно поле "city", посоветуйте, как лутьше сделать, чтобы потом можно было производить выборку с меньшей нагрузкой?

Также чтобы при выводе записей недвижимости можно было выводить названия городов а не их ID

 

[Димон]

В этом же разделе почитай: http://phpclub.ru/talk/showthread.php?s=&threadid=107908&rand=3
Такая же ситуация.

Вообще, чтобы уменьшить нагрузка всегда делай выборке минимально необходимых данных, т.е. старайся реже использовать SELECT * , а явно указывай названия столбцов (если, конечно, не нужны все столбцы).
И пользуйся конструкцией LIMIT x, y , т.е., если у тебя в базе 10 000 записей, то, скорее всего, ты использешь постраничный вывод. Допустим тебе надо вывести записи с 8 800 по 9 000. Без использования LIMIT БД перелопачивает всю таблицу. С LIMIT же просматриваются толькл эти 20 записей.
Также старайся отправлять объединять запросы, а не слать кучу мелких - это настоящее бутылочное горлышко при работе с БД.

 

[zerkms]

Без использования LIMIT БД перелопачивает всю таблицу. С LIMIT же просматриваются толькл эти 20 записей.

если придираться, то и при LIMIT 8880, 20 будет "просмотрено" 9000 записей

-~{}~ 01.05.08 13:33:

Также старайся отправлять объединять запросы, а не слать кучу мелких - это настоящее бутылочное горлышко при работе с БД.

а вот это - ещё более спорное утверждение...

-~{}~ 01.05.08 13:38:

DenVeroid
а ты вообще хоть как-нибудь пробовал задачу решать сам? наброски покажи

чтобы потом можно было производить выборку с меньшей нагрузкой?

делай так как тебе удобно. как только что-то начнёт тормозить - тогда и будешь искать "что тормозит".

 

[Димон]

Автор оригинала: zerkms
делай так как тебе удобно. как только что-то начнёт тормозить - тогда и будешь искать "что тормозит".

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

Вообще, при планировании запроса, бывает полезно использовать самописный тест скорости выполнения запроса: создаешь рандомную таблицу или несколько таблиц на 10 000 - 100 000 записей и кидаешь к ней запрос, походу фиксируешь время начала и окончания выполнения через php. Для составления правильного запроса этого вполне достаточно для начала. Ну а дальше, по ситуации.

 

[zerkms]

Надо сразу делать нормально

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

Вообще, при планировании запроса, бывает полезно использовать самописный тест скорости выполнения запроса:

производительность запроса на этапе проектирования и программирования оценивается "на глазок" EXPLAIN'ом. потом - вполне можно обойтись консолью mysql безо всяких скриптов

-~{}~ 01.05.08 21:50:

По поводу объединения запросов я имел ввиду, что при составлении обращения можно одну и ту же информацию получить как в одном - двух запросах, а можно и в цикл поставить.... Использовать, к примеру, сортировку и группировку силами самой БД и получать готовые данные.

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

 

[StUV]

в любом случае, такая простая структура конвертится в любую другую с сохранением внешних связей без всяких проблем

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

 

[Ashotovich]

По поводу иерархической структуры - а что мешает создать одну таблицу для "Страна, Регион, Город" типа "id-name-parent_id"?

 

[no_santa]

Ashotovich размер таблицы. Я разбил на три. Города - Ключи городов - Регионы. Теперь время исполнения скрипта с запросом < 0.003 сек.
Кстати, у кого-нибудь есть таблица Города/Регионы?
Я сделал таблицу из городов евразии, но она не связана с регионами.