База данных, Моделирование валюты, Стратегии локализации - PullRequest
Новая
       27

База данных, Моделирование валюты, Стратегии локализации

4 голосов
/ 11 марта 2012

Какова наилучшая стратегия для хранения информации о продуктах электронной коммерции (т.е. цена продукта, текущая цена) в среде с местной валютой?

Я столкнулся с проблемой в Spree, движке электронной коммерции для Ruby on Rails , касающемся отображения валюты с использованием локализации, разделителей, точных цифр и т. Д.

Однако, разрешение отображения цены стало более сложным, , когда мы должны были выяснить, должно ли хранение значений в базе данных включать в себя разделитель / прецизионные цифры локализации или быть нормализовано . Решение включает в себя как локализацию отображения значения, так и потенциальную нормализацию хранимого значения в базе данных. Но я не уверен, что это стандартная практика (очистка данных для соответствия «стандартной» точности и разделитель ИЛИ изменение модели, чтобы взять в поле «валюта», и сохранение стандарта ввода.

ПРИМЕР:

Если продукт из США (используется файл локализации "en") по цене 2,99, то он сохраняется в базе данных как 2,99. Если сайт обновляется для локализации для Германии (с использованием файла локализации "de"), то его цена составляет 2,99. Но следует ли хранить обновления для этой цены (и cost_price) как 2,99 или 2,99? Если они хранятся в 2,99, и значение возвращается обратно в представление из модели, то локализация изменит значение на 2,99.

Я не решаюсь стандартизировать ввод данных пользователем без их ведома. Является ли стандартизация валютных норм нормальной или модель должна измениться для обработки мультивалютных форматов?

Еще одна проблема, на которую следует обратить внимание, это то, что хотя движок Spree может изменять локализацию, я не верю, что он пока может изменяться по требованию пользователя. Так что технически это не мультивалютная среда, я полагаю? Я хотел бы выбрать вариант, который можно масштабировать.

СВЯЗАННЫЕ ВОПРОСЫ:

  1. дизайн базы данных: мультивалютные счета
  2. Моделирование валюты в базе данных

1 Ответ

3 голосов
/ 11 марта 2012

Проблема в том, что у вас есть товар, продающийся в разных режимах обмена с разными культурами. Скажем, в Америке это 1450,00 долларов США, а в Германии - 1111,11 евро. Есть два основных фактора:

A. Есть разные цены в разных валютах
B. Существуют разные способы отображения суммы денег в разных культурах

Что касается A, вы могли бы

  • хранить в одной цене / валюте и на лету корректировать по разным курсам
  • или настроить по ночам
  • или просто разные цены в разных странах

Я бы пошел с таблицей цен, разделенных по валютам. вероятно, целесообразно обновлять каждую ночь: 

ProductId  Currency  Price
1          EUR       1111.11
1          CAD       1436.65
1          USD       1450.00

Эти значения должны быть числами, чтобы при необходимости их можно было легко вычислить. Используйте десятичное число (10,2) в вашей базе данных

Относительно B

Вы должны отформатировать выбранную цену для данной культуры при отображении. Представьте, что американец платит в евро. Что они хотят увидеть? Ваш вывод будет выглядеть так, в зависимости от выбранной культуры:

Скажите, что это 1111,11 евро 

Culture  Price    Long Name
de_de   1.111,11  (German)
fr_ca   1 111,11  (Quebec)
en_us   1,111.11  (US English)

Это все одинаковое количество, просто отформатированное по-разному, в зависимости от предпочтений пользователя.

Если пользователи вводят в разных количествах, вам также придется проанализировать их значения на основе выбранной культуры. Ознакомьтесь с возможностями Yii (извините, PHP) L10N и I18N .

Примечания:

Что бы вы ни делали, не храните это как число с плавающей запятой, иначе со временем вы получите незначительные ошибки. Используйте десятичный тип

Попробуйте использовать 4 цифры после десятичного знака для полей, которые являются результатом вычислений

...