Нужна помощь с концепцией базы

stasionok

Мой дом здесь!
Регистрация
29 Ноя 2012
Сообщения
328
Реакции
377
Собираем базу спортивных секций города.
Поля: Название;Категория;Возраст;Время занятий;Дни занятий;Телефон;Адрес;Цена;Сайт
Естественно, для 1 названия могут быть много строк, где различается любое из полей.
Т.к. базу собирает человек, а названия организаций могут быть длинными и, учитывая длительность самого процесса, результат приведет к тому что могут появляться дубли названий - опечатка, какая-нибуть лишняя кавычка и т.п.
Кроме всего прочего после создания базы и импорта её в движок сайта необходимо её постоянно актуализировать и обновлять.
Вопрос: Каким образом организовать такой процесс?
 
1 таблица:
ID - Организация

2 таблица
ID- ID Организации - Название филиала - Телефон - Адрес - Сайт

3 таблица
ID - Название секции

4 таблица
ID - ID Филиала - ID секции - Время занятий - Дни занятий - Возраст

Как-то примерно так...
 
А как избежать дублей?
 
ID - Первичный ключ
Название - Уникальный ключ

Так создать 2 одинаковые конторы не получится, ровно как и 2 одинаковые секции...

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

Перед добавлением - проверять наличие аналогичной организации:
- autocomplete по словам из названия организации;
- сравнение адресов, телефонов и других данных;
- проверка адреса через геопоиск Яндекс-карт;
... и тд.

Ручная модерация;

В справочнике - кнопка "пожаловаться" с ajax-формой для посетителей сайта...
 
Как раз таки у секции может быть собственный сайт, контактные телефоны и даже несколько адресов, отличных от адреса головной организации.
Ну и обязательно нужны поля дополнительной информации и фотографий.
Адрес опять же лучше сразу привязывать к картам (например, яндексу или OSM), чтобы отображать интерактивную карту.
 
Если сайт еще не сделали, возможно стоит посмотреть в сторону nosql баз данных, т.к. может быть множество телефонов, адресов, занятий, время работы может не попадать под общую концепцию. На nosql это делается гораздо легче и быстрее.
 
Давайте прекратим бесполезный флуд.
Узнали новое слово NoSQL - молодцы. Теперь почитайте когда оно применяется. А именно - на тяжёлых БД с необходимостью быстрого доступа к системе. Я не знаю ни одного каталога, который бы потребовал применения NoSQL (речь не о глобальных как у Яндекса, а о каталоге в рамках города). Не стоит расценивать как оскорбление, просто Вам нужно больше опыта чтобы знать где какие технологии нужно применять. Так на NoSQL можно перевести и сайт сельского клуба города Мухосранск для "кому за 110", который посещает только админ, да гугл - только зачем? Эта технология только для очень высоконагруженных платформ. Иначе - лишнее...

Про привязку к картам - не нужно. Карту можно элементарно получить имея адрес. А лишняя работа сейчас не нужна.

По AJAX - тоже лишнее. Оператор БД не блондинка и красивая загрузка ему не нужна - лишняя работа.

Зато идея по проверке дублей высказана хорошо и ручная модерация тоже нужна. И опять же Prometeus верно меня поправил на счёт адреса, телефона и сайта. Но я не спроста добавил пункт "Филиал"... Именно его можно использовать для этой цели. Хотя может и есть смысл оптимизировать ещё сильнее.
 
Спасибо за помощь.
Автокомплит и ручную модерацию применили, за едицу принял группу - часть организации. относительно её уже строится организация в которой таких групп с разными параметрами скок угодно. ну и категория в которой собираются организации.
 
Делал подобную базу для детских лагерей. Автокоплит и подсказки аля "это ваша организация?" с выводом похожих ни к чему не привели. Люди не смотрят это. Только ручная модерация.
PS: Если кто помнит, у одной известной соцсети была проблема, когда было множество названий одних и тех же учреждений. Решили только ручной модерацией.
 
Назад
Сверху