Много малко автори на бази данни споменават предизвикателствата на глобализацията и локализацията по някакъв смислен начин. Има подобна липса на предвидливост от архитектите на бази данни. Факт е, че много автори и дизайнери често са много „самоцентрични“:те създават (или пишат за) модели на данни, които правилно обработват местните часови зони, адреси и т.н.
Самоцентричният подход има голям проблем:полученият модел ще поддържа само локални данни. В днешния свят, подхранван от интернет, приложенията често са неочаквано достъпни от потребители по целия свят. Трябва да подкрепим възможно най-голяма гъвкавост за тази международна аудитория. Следователно трябва да проектираме нашите модели на данни с глобализиран подход.
Имам късмета да работя в многонационална и многоезична среда, така че научих как проблемите на глобализацията могат да се справят в началото на проекта. Имайки това предвид, събрах седем важни точки за създаване на модел на данни, който ще поддържа международна употреба.
1. Форматиране на числа
Има две неща, които трябва да имате предвид, когато разглеждате форматирането на числата:изходът, който потребителите виждат (т.е. форматът), и основният тип данни.
Не трябва да се притеснявате за това как числата ще се показват във вашия модел на данни – системата на базата данни ще се справи със съхранението на десетичните числа и приложението ви трябва да се приспособи към начина, по който се показват десетичните числа (.” или “,” като десетичен знак точка, например). По същия начин не трябва да се притеснявате кой разделител на хилядите (като точка или запетая) ще използва вашият модел на данни.
Ето въпросът: Изберете вашите типове данни правилно при моделиране. Вашето приложение трябва да обработва изходното форматиране.
Например, в този прост модел на приложение на метеорологична станция, метеорологичните измервания (температура, влажност, валежи) се съхраняват като числа с плаваща запетая. Но информацията за цената е десетична, подобно на GPS координатите на всяка метеорологична станция.
2. Валути и обменни курсове
Ако съхранявате информация, свързана с валути, тогава трябва да съхранявате правилния брой десетични знаци за всяка валута. Повечето валути имат два знака след десетичната запетая, но някои нямат нито един (т.е. чилийското песо), един (мадагаскарският ариари), три (тунизийски динар) или дори четири знака след десетичната запетая (Чилийската Unidad de Fomento, разчетна единица, използвана за изразяване на диапазон от ценови стойности.)
Така че, уверете се, че вашите полета „количество“ в модела на данни поддържат повече от два знака след десетичната запетая – докато четирите знака след десетичната запетая са много рядки, това се случва. Три знака след десетичната запетая са по-често срещани. Например динари в шест различни държави (Бахрейн, Ирак, Йордания, Кувейт, Либия, Тунис) и риалите в една държава (Оман) изискват три знака след десетичната запетая.
Точка номер 1: Изберете вашия тип данни правилно при моделиране.
Друг важен момент, свързан с валутите, са обменните курсове. Те изискват още по-голяма прецизност. Много системи предоставят само 4-6 значими цифри във валутните курсове; понякога има мащабиращ фактор между валути, които имат значително различни стойности. Въпреки това, четири или шест значещи цифри не означават непременно, че ще има шест знака след десетичната запетая. Проверете обменния курс между индонезийска рупия и евро:0,0000668755. Това са много десетични знаци, които да съхранявате във вашето поле за обменен курс.
Точка номер 2: Може да се наложи Вашият модел да се справи с високо ниво на точност – много десетични знаци – когато става въпрос за обменни курсове.
По-долу сме създали пример за онлайн магазин с цени. Добавихме и проста таблица (маркирана с аква), която съхранява валутни курсове, включително исторически обменни курсове. Всеки ред в exchange_rate таблицата е свързана с валута (currency_id , което е кодът на валутата по ISO 4217). Разрешаваме да се съхранява един обменен курс за всяка валута в определен ден (rate_date ) и има един активен обменен курс за всяка валута.
Очевидно ще ви е необходима допълнителна информация, за да използвате тази таблица с тарифи. Например, спрямо коя основна валута са определени тези обменни курсове? Евро или щатски долари може да са типични, но вашето приложение ще се нуждае от точна информация тук.
Като алтернатива, по-сложен модел би могъл да съхранява валутни двойки, средния курс (или банковия курс) и курсовете „купува“ и „продава“ между тези валутни двойки.
Точка номер 3: Вашият модел трябва да има достатъчно информация, за да може приложението да използва правилно данните.
3. Телефонни номера
Често съм виждал системи, които поддържат само десетцифрен телефонен номер в Северна Америка с трицифрен код на региона, трицифрен обмен и четирицифрен абонатен номер (т.е. 012-345-6789). Това пристрастие е разбираемо до известна степен; хората създават системи, които поддържат техните местни потребители. Въпреки това, моделирането на данни не трябва да пренебрегва възможността глобалните потребители да имат достъп до вашата система. (Забележка:Десетцифрената дължина може да се използва и за други номера, като френски мобилни телефони, но форматът е различен (т.е. 06 12 34 56 78).)
Да вземем това като пример:Да предположим, че живея точно извън френската граница, но работя във Франция. Следователно, въпреки че може да се наложи да използвам френски приложения и доставчици на услуги, моят мобилен телефон не е френски номер. Системи, които изискват десетцифрен мобилен номер, започващ с 06 или 07, няма да работят за мен. За да взема френски железопътни билети, да купя билети за концерт във Франция (и т.н., и т.н.), ще бъда принуден да взема френски телефонен номер. Досадно, меко казано.
Ето въпросът: Когато ограниченията за телефонни номера са вградени в модела на данни, ще са необходими модификации на модела на данните за подкрепа на неместни потребители. В идеалния случай, достатъчно гъвкавост трябва да бъде включена в модела, за да се справят с всички възможни случаи.
Един по-логичен модел на данни би поддържал телефонни номера с различна дължина (до 16 цифри в някои области) и нецифрови знаци (като универсалния символ „+“ за международен телефонен номер). Разбира се, някои приложения могат да извършват повече валидиране чрез прилагане на „локални правила“, с които местните разработчици биха били по-запознати. Други приложения може да използват локални телефонни номера за достъп до други източници на данни, като например потвърждаване или извличане на адрес въз основа на телефонен номер.
Моделът на данни трябва да поддържа гъвкавост при съхранение на информация. Приложението или неговият потребителски интерфейс могат да бъдат по-ограничителни или да извършват допълнителна проверка.
4. Адреси
Като американец, живеещ в чужбина, често намирам примери и модели за модели на данни, които са твърде ориентирани към Америка. Например неамериканец може да не разбере какво е Zip+4 е и следователно няма да разбере защо авторът заявява, че този домейн трябва да има характеристика NOT NULL.
Този амероцентричен възглед присъства дори в книгите. Например, вземете доста обширната книга „Модели на модели на данни. Конвенции на мисълта” от Дейвид К. Хей. Много сложното обяснение на г-н Хей за адреси, обекти, географски местоположения, парцели и елементи на географска структура включва примери от Канада, но дори и така, тази информация може да не се схване лесно от всеки.
Моделите на г-н Хей казват, че атрибутите на адреса ще включват:
Текстът на адреса плюс поне „град“, „щат“ и „пощенски (ZIP) код“.
Сега г-н Хей бърза да обясни в бележка под линия, че:
Контекстът на модела ще определи дали този атрибут е „пощенски код“ или „пощенски код“. Ако организацията-клиент ще работи изцяло в Съединените щати в обозримо бъдеще, може да се направи предположение за деветцифрен, двучастен цифров "пощенски код". Ако не, „пощенски код“ трябва да стане „пощенски код“ и не са възможни предположения за форматиране.
Той обаче пропуска да спомене, че „щат“ може да бъде щат в САЩ, провинция в Канада или атрибут с нула за почти всяка друга страна, тъй като „щати“ в рамките на държави рядко съществуват извън САЩ, Канада (където те се наричат провинции, но функционират по подобен начин) и Австралия. Разбира се, други държави имат провинции и региони, но те рядко се използват като част от адрес.
За да илюстрирам колко сериозен може да бъде този проблем с адреса, направих модел на данни както за американски, така и за неамерикански адреси. (Забележка:Това не е пълният модел.)
PrimaryPhone на US_Customer таблицата съхранява само телефонни номера с десет или по-малко знака. Международният дизайн на Customer PrimaryPhone на таблицата атрибут позволява телефонен номер от 15 цифри плюс „+“, което е максимумът, определен от E.164.
TimeOffset атрибут в US_Customer таблицата позволява само четири часови зони:източно време, централно време, планинско време и тихоокеанско време (съхранено в модела на данни като:0 =източен, 1 =централен, 2 =планинско време, 3 =тихоокеанско време). Между другото, това дори не обхваща всички часови зони в САЩ и техните територии. За разлика от това, Timezone атрибут в Customer таблицата съхранява международния код за часовата зона на клиента, независимо къде се намира.
След това нека разгледаме пощенския/пощенския код. САЩ изисква 5-цифрен пощенски код (Zip на US_Address таблица) плюс незадължителния ZIP+4 (Zip4 на US_Address таблица). Address таблицата има по-гъвкав PostCode поле. Освен дължината, няма ограничение за информацията, която може да се съхранява в PostCode; разбира се, приложението може да приложи проверки на пощенските кодове.
Забележете също, че дизайните в САЩ и извън САЩ имат поле за региони в рамките на дадена държава (State в US_Address таблица и Region в Address таблица), но американският дизайн изисква да е включено съкращение от 2 знака за състояние. Също така имайте предвид, че дизайнът в САЩ не приема международни адреси, докато версията на международния адрес го приема (оттук 2-знаковият ISO код на държавата на Address таблица).
Ето въпросът: Не ограничавайте своя модел на данни от адреси до едно населено място; оставете достатъчно място за различни стилове.
5. Форматиране на дата и час
Моделите на данни не трябва да се занимават с множество формати за дата и час; приложението обработва действителния дисплей. Това може да стане по различни начини:
- Стилът за първи месец, често срещан в Северна Америка и другаде:mm-dd-yyyy
- Стилът първи ден, който е по-често срещан в Европа:дд-мм-гггг
- Стилът за първата година, използван като формат за дата по ISO 8601:гггг-мм-дд
Ето въпросът: Това може да се повтаря, но ще го кажем отново:изберете правилно типовете си данни при моделиране. Това ще улесни кода на приложението да интерпретира и показва съхранените стойности.
Друг елемент от тази категория може да е малко неочакван:кой ден започва седмицата. За някои това е неделя; за други е понеделник (и след това има персийския календар, който започва седмицата в събота).
Часовете също трябва да се показват по удобен за потребителя начин. Не забравяйте, че докато моделът ви на данни не се нуждае от множество времеви формати, може да съхранявате предпочитанието за време на потребителя 12- или 24-часов формат.
Това ни води до часови зони.
6. Часови зони
Не е необичайно да намерите приложения, които позволяват на потребителите само няколко избора на часови зони:източно време, централно време, планинско време и тихоокеанско време. Когато видя това, знам, че имам работа с дизайнер на приложения, ориентиран към Amero. Някои дизайнери позволяват часовата зона да бъде изразена като отместване от (обикновено) GMT или UTC. Въпреки това, мнозина правят грешката да разрешават само отмествания на цяло число, без да осъзнават, че някои страни (Индия, Иран, Пакистан, Афганистан и други) не са целочислени компенсации. Те са частично различни:стандартното време в Индия е UTC+5:30. Някои местоположения дори имат по-малко частично изместване, като например стандартното време в Непал – UTC+05:45.
Преди време писах за модел за онлайн база данни от анкети. Тук добавих часова зона към потребителската таблица, за да можем да показваме дати/часове в местните часове на потребителите.
За повече информация относно датите, часовете, часовите зони можете да се обърнете към стандартното представяне на дати и часове по ISO 8601 или тази статия в Уикипедия.
Ето въпросът: Научете се да мислите глобално, а не само локално.
7. Многоезична поддръжка
Има много случаи, когато вашето приложение може да се наложи да предостави многоезична поддръжка. От гледна точка на модела на данни може да се наложи информацията да се съхранява на множество езици; обаче по-голямата част от езиковата работа трябва да бъде обхваната във вашето приложение. Внедряването на многоезична поддръжка е извън обхвата на тази статия, но вече го обсъдихме в този блог.
Локализацията е много важна и трябва да се работи правилно. Както вече посочихме, това означава повече от просто поддържане на различни езици; става дума и за предпочитаните формати за дати, часове, валути и дори десетични индикатори.
Моделиране на данни? Мислете глобално
Докато създавате своя модел на данни, помислете за потенциалното международно използване на вашето приложение и неговата база данни. Мислете глобално по време на фазата на проектиране и ще избегнете някои проблеми по-късно – поле за телефонен номер, което приема само 3-цифрени + 3-цифрени + 4-цифрени, работи добре в САЩ, но не толкова добре в Китай или Индия.
Подготвени ли са вашите бази данни да станат глобални? Вашата цел трябва да бъде да осигурите гъвкавост, без да създавате огромна сложност.
