 |
|
|
 |
|
|
|
| народная забава - избиение чайника |
|
IMHO, только IMHO и ничего кроме IMHO
Постов: 104
Дата регистрации: 04.03.2005 |
Знаю, что тема уже обсуждалась. Знаю, что надо что-то сделать, а потом спрашивать как это сделать. Знаю, что на форумах такие вопросы не решают... И ещё знаю, что главная забава на форуме - битье ламеров. Предлагаю свою тушку для избиения.
Задача - создаем некий справочный массив. Объекты базы данных имеют такое свойство как география распространения, ареал обитания. Вопрос в следующем - как описать этот самый ареал, чтобы, с одной стороны, было возможно выбрать охват разного уровня (один город, два региона, полконтинента и т.д.), а с другой - дать возможность пользователю логично и легко делать выборки, объединяющие несколько региональных единиц. Свой вариант пока показывать не хочу, чтобы не задавать изначально колею. Если у кого будут идеи - рад выслушать в любой форме. Чуть позже изложу свой ламерский взгляд на этот вопрос. Спасибо! ;) |
|
--------
Все сказанное и написанное является личным мнением автора, может не совпадать с мнением любых иных авторов, и может быть ошибочным. Автор не несет никакой ответвенности за любые последствия, наступившие в результате использования его мнения. |
 |
0 |
 |
0 |
| Комментарий понравился? |
|
0 |
|
0 |
   22.02.2011 13:15 |  |
|
|
|
pogurcov
Постов: 1989
Дата регистрации: 16.04.2007 |
для: Антрек©
Я мало чего понял, кроме ваших призывов к избиениям. Принцип работы с регионами Яндекса (например в директе) чем не мил? |
|
|
0 |
|
0 |
| Комментарий понравился? |
|
0 |
|
0 |
22.02.2011 14:25 | |
|
|
|
Постов: 2352
Дата регистрации: 18.12.2006 |
для: Антрек©,
Максимальную гибкость обработки обеспечивает классическая реляционная модель данных. Но на практике, особенно если речь идет о высоко нагруженных системах, чаще всего от классики сильно отклоняются для оптимизации под конкретное использование базы - это уже вопрос специального опыта. Поэтому не изобретайте велосипед. Если нет соответствующего экспириенса, просто заплатите деньги специалисту. Получите оптимальный вариант, и может даже не один, а несколько (под разные условия применения, и при правильно поставленной задаче, разумеется). |
|
|
0 |
|
0 |
| Комментарий понравился? |
|
0 |
|
0 |
22.02.2011 14:32 | |
|
|
|
IMHO, только IMHO и ничего кроме IMHO
Постов: 104
Дата регистрации: 04.03.2005 |
угу, всех запутал... Уточняю. Меня больше всего волнует юзабилити, а не техническая сторона построения базы. Есть... ну скажем... товары. Они могут продаваться в одном городе, в нескольких городах, в одной стране и т.д. вплоть до глобального присутствия. Каким образом описать этот признак (система записей в таблице "Регион"). Мне пока ясно, что надо обязательно иметь списки городов и стран. С этим никаких проблем. Но вот дальше туман. То есть существует вероятный сценарий, когда понадобиться запрос по региону: несколько стран или городов. Логично ввести две категории этих самых территориальных регионов - выше и ниже стран. Но тут столкнулся с неоднозначностью. Два примера. В России существуют федеральные округа и входящие в них области, края, республики и др. образования. В Европе есть ЕЭС и есть регионы типа Северная Европа, Балканы и т.д. То есть список получается не однородный. Как это решить технически мне понятно, не понятно как это представить пользователю: выдавать ему одним списком все возможные варианты регионов или предлагать сначала выбор класса региона...
для: koska© Спасибо, специалисты по базам данных есть. Но именно что нужно "правильно поставить задачу". Этим я сейчас и занят.
Насчет оптимального варианта от специалистов... оно конечно... но, во-первых, несколько оптимальных вариантов это уже как-то удивляет ( ;) ), а во вторых, думаю этого абсолютного оптимального варианта нет и быть не может. Нужен некоторый допустимый и удобный вариант.
И про велосипед. Это я понимаю, я просто вижу в сети множество разных велосипедов. Вот даже со стандартами названий стран никак к одному "велосипеду" специалисты прийти не могут: существует международная классификация, национальная классификация, классификации разных международных организаций (ФИФА, МОК и т.д.). У ЦРУ своя система регионального деления и свой список стран. И все отличаются... ;)
------------------
Отредактировано: Антрек | 22.02.2011 16:55 |
|
--------
Все сказанное и написанное является личным мнением автора, может не совпадать с мнением любых иных авторов, и может быть ошибочным. Автор не несет никакой ответвенности за любые последствия, наступившие в результате использования его мнения. |
|
0 |
|
0 |
| Комментарий понравился? |
|
0 |
|
0 |
22.02.2011 16:52 | |
|
|
|
Постов: 1035
Дата регистрации: 20.06.2007 |
для: Антрек© по-моему, Вы загоняетесь.
Определите регионы по категориям, например так:
Города / федеральные округа / Международные обьединения и союзы стран / Части света
Таблица БД получится в таком виде
Лос Анжелес/Невада/США/НАТО/Америка
Москва/Центральный федеральный округ/Россия/ЕвразЭС/Евразия
И выбор делайте по любому сочетанию этих категорий.
|
|
|
0 |
|
0 |
| Комментарий понравился? |
|
0 |
|
0 |
22.02.2011 17:26 | |
|
|
|
Постов: 2352
Дата регистрации: 18.12.2006 |
Цитата, автор Антрек:
Насчет оптимального варианта от специалистов... оно конечно... но, во-первых, несколько оптимальных вариантов это уже как-то удивляет ( ;) ) |
Естественная ситуация для многокритериального выбора. Постановка задачи может быть такой, что вы вообще получите множество так называемых оптимальных в смысле Парето решений (т.е. грубо говоря таких, каждое из которых лучше остальных по одним параметрам, и хуже их же по другим параметрам). В случае проектирования модели данных такое сплошь и рядом случается - одни решения выигрывают по простоте реализации и последующей поддержки, другие - по надежности, третьи - по скорости и т.д...
Технически нет вообще никаких проблем реализовать полную иерархию административного-территориального деления для любой точки на глобусе с удобным (настраиваемым) представлением для пользователей - это только вопрос времени и денег. Стоить это будет достаточно дорого, и при том что 99% пользователей базы никогда не полезут в дебри - им достаточно 2-3 уровней иерархии. Оно надо?
Юзабилити и максимальная гибкость сочетаются плохо. Приземляйте постановку задачи...
P.S. ...или конкретно опишите несколько сценариев использования вашей базы данных - я не исключаю вариант банального непонимания (моего) :) |
|
|
0 |
|
0 |
| Комментарий понравился? |
|
0 |
|
0 |
22.02.2011 17:53 | |
|
|
|
 | Только зарегистрированные пользователи могут оставлять сообщения в этом форуме |
|
|
|
|
|
© "ООО Состав.ру" 1998-2024
тел/факс: +7 495 225 1331 адрес: 109004, Москва, Пестовский пер., д. 16, стр. 2
При использовании материалов портала ссылка на Sostav.ru обязательна!
Администрация Sostav.ru просит Вас сообщать о всех замеченных технических неполадках на E-mail
|
|
|
|
