А в чём проблема? Подсказка: цены разные не только в разных магазинах (и, кстати, в разных валютах), а ещё и разные для разных категорий клиентов, ещё на них действуют сезонные скидки, всяческие акции типа "купи два, третий в подарок" итп.

virtuu443Хочется более изящно и красивое решение, думал даже хранить инфу в xml файле,
Ну и представления у Вас об изяществе и красоте

virtuu443как-то так... но как правильней?
Правильнее не делать глупостей и хранить реляционную информацию как реляционную информацию.

virtuu443 далее 2 варианта:
Плюньте в лицо тому, кто Вам сказал такую глупость. Далее куда больше вариантов

Похоже, Вам прежде всего стоит крепко-накрепко понять, что цена - вовсе не атрибут товара. Атрибут товара - это сорт, цвет, размер, фасовка, условия хранения, в общем, то, что не склонно меняться. Похожий товар с другими атрибутами - чаще всего другой товар, другая запись в справочнике (скажем, если продавец изменил фасовку). В "первичном справочнике товара" нет атрибута "цена", соответственно никакой "копии для магазина с изменёнными значениями некоторых параметров" нет и не будет.

У вас точно будет "первичный справочник товаров", обычно это группа таблиц. Каких именно - зависит от специфики, нет смысла фантазировать. Также у вас точно будет сущность "цены", в смысле "цены на те или иные товары в тех или иных условиях". То есть, например, десяток куриных яиц Гомельской птицефабрики, первого сорта, во второй половине срока хранения, при покупке в московском отделении мелкооптовой партией юридическим лицом в статусе "постоянный партнёр", с первого по двадцатое января 2011-го года будет стоить восемьдесят центов в пересчёте на рубли по указанному курсу на день покупки. Это, собственно, обязательный минимум.

Весьма вероятно, у вас будет сущность "прайс-лист". Дело в том, что вводить указанные атрибуты для каждой цены каждого товара - дело хлопотное и часто не нужное. Куда чаще бизнес пишет "прайс-лист с 01.01.2011 по 20.01.2011 для постоянных партнёров в Москве" и вносит туда цены если не по всему набору, то по существенной группе товаров, соответственно, часть атрибутов, а то и почти все, переезжают из "цены" в "прайс-лист".

В любом случае, делать "свою таблицу для каждого магазина" - последнее дело, бредовый офигенный геморрой на пустом месте. Если выбран какой-нибудь Paradox, который не тянет количества записей, надо просто поменять СУБД на что-то более нормальное.

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

miksoft, категорически утверждать, наверное, действительно не стоит. Но всё же имхо оно будет зависеть от страны, от категории клиентов, итп.... от чего-то более объективного, нежели "магазин". Сегодня один открыли, завтра другой закрыли - рабочие моменты, не повод менять описания. Разве что франчайзинговые схемы, да и то..

miksoftА в некоторых других магазинах .. более содержательное описание товара.
Ну так это стандартные поля short_description, long_description, о чём Вы собственно и упоминаете дальше.

miksoftА поскольку таких магазинов и таких товаров относительно мало, то написание этих более содержательных описаний отдано на откуп самим магазинам.
Так и пусть. Пусть short_description по бизнес-процессу заполняют "сотрудники центра", а long_description - "сотрудники магазинов". Не вижу ни проблемы, ни необходимости тупо дублировать работу, заполняя long_description в каждом магазине отдельно.

miksoftа) это делалось в уже сложившейся системе (в т.ч. в организационном плане).
Если система не позволяла тривиальную доработку, то оно, безусловно, печально. Но согласитесь, это ни в малейшей степени не довод для проектирования новой БД, о чём спрашивает топикстартер.