Есть торговый центр, специализирующийся на около-строительных материалах – куча павильонов маленьких фирмочек. Порядка 150 фирм, у каждой от 20 до 300 товарных позиций(если считать тех, кто торгует метизами). Товарные позиции процентов на 50% совпадают. Руководство планирует внедрить самонаписанную :-) ИС с информацией по товарам у арендаторов павильонов + поиск по названию, цене и т.п.
Сбор данных – для тех, у кого есть компы – генерят файлик с инфой, который заливается в БД. Те, у кого нет – предоставляют распечатку и за отдельную плату девочки-секретари превращают её в тот же файлик с инфой. Платформа MSSQL+ASP.NET. Планируется, что покупателям система будет доступна на нескольких терминалах с тач-скринами.
Чёткого ТЗ, естественно, нет :-) Такое ощущение, что надо реализовать что-то среднее между price.ru и терминалами поиска фирм в больших ТЦ (говорят, что где-то видели такое). Поэтому хочется навернуть побольше, дабы впоследствии дописывать поменьше. Во всяком случае, поменьше трогать структуру БД.
Самый главный вопрос - организация импорта данных. Тут вижу несколько вариантов.
1. Собрать расширенную номенклатуру товаров по фирмам в бумажном виде (название, описание, кто производит, сферы применения и т.п.). На её основании разработать свою, прописать ID каждой номенклатурной единицы и впоследствии требовать xml-файлы с данными уже в своём формате. Т.е. выдать фирмам ID каждого товара и обязать их передавать эти данные в обменном файле. В случае, если появляется новая позиция – добавлять её в номенклатуру и обновлённые данные предоставлять фирмам.
2. Начало аналогично первому – создаём свою номенклатуру, но фирмам ничего не выдаём. В БД заводим дополнительную таблицу соответствий между “названием позиции в импортируемом файле фирмы”-“номенклатурной единицей в БД”. При импорте файла – загружаем из него данные в БД и проставляем соответствия. Соответствия сохраняются на всю жизнь. При этом варианте - наибольшие затраты будут при первоначальном проставлении соответствий. Дальше будет легче, т.к. новые позиции добавляются редко.
3. Не заморачиваться созданием доп. структур в БД, а пихать всё подряд из файла импорта. Большая часть ответственности за качество инфы и удобство поиска для клиента сразу перекладывается на плечи фирм. Но чувствую, что толку в таком случае будет мало :-(
4. Ещё вариант, вытекающий из 2-х предыдущих – оставить только какие-то “глобальные” категории товаров. По ним и проставлять соответствия. И думать над механизмом поиска.

Прощу прокомментировать. Сам склоняюсь к вариантам 2 или 4. Но если кто делал подобное сам, или знает, как стоит сделать (например, как сделано на price.ru), с удовольствием выслушаю.

Фото точно будет. Каким образом прикрутить - это опять же вопрос схемы БД.
Система поиска места на карте ТЦ не актуальна в виду чёткой нумерации (№ряда\№павильона). Т.е. если нашёлся товар - то найти павильон, это не опреблема.

Девочек - плохо говорящих по-русски - точно нет. Весь вопрос в переносе данных тетрадка -> БД. Как вариант - первый импорт возложить на сотрудников арендодателя-ТЦ. С заведением таблицы-истории (фирма-какие товары импортировались). Первый импорт будет долгим, нудным, со вводом данных руками. Но зато потом, можно раздавать фирмам листы с их же номенклатурой из предыдущего импорта, где они бы просто проставляли текущие цены, ну и дописывали новые позиции, в случае их появления.

Но это всё лирика. Нужны мнения по сабжу.

To Q:

В таком варианте надо балансировать между подробностью категоризации номенклатуры и удобством текстового поиска: либо в 3-4 тыка пальцем в экран по дереву категорий дойти до нужной категории, либо долго тыкать пальцами в тот же экран, ища верный вариант написания названия товара.