Bardzo niewielu autorów baz danych w jakikolwiek znaczący sposób wspomina o wyzwaniach związanych z globalizacją i lokalizacją. Podobny brak przewidywania ze strony architektów baz danych. Faktem jest, że wielu autorów i projektantów jest często bardzo „samocentrycznych”:tworzą (lub piszą o) modele danych, które właściwie obsługują tylko ich lokalne strefy czasowe, adresy itp.
Podejście skoncentrowane na sobie ma duży problem:uzyskany model będzie obsługiwał tylko dane lokalne. W dzisiejszym, napędzanym Internetem świecie, użytkownicy na całym świecie często niespodziewanie uzyskują dostęp do aplikacji. Musimy wspierać jak największą elastyczność tej międzynarodowej publiczności. Dlatego musimy projektować nasze modele danych z globalnym podejściem.
Mam szczęście pracować w bardzo wielonarodowym i wielojęzycznym środowisku, więc na początku projektu nauczyłem się, jak radzić sobie z problemami globalizacji. Mając to na uwadze, zebrałem siedem ważnych punktów dotyczących tworzenia modelu danych, który będzie obsługiwał wykorzystanie międzynarodowe.
1. Formatowanie liczb
Przyglądając się formatowaniu liczb, należy wziąć pod uwagę dwie rzeczy:dane wyjściowe, które widzą użytkownicy (tj. format) oraz bazowy typ danych.
Nie musisz się martwić o to, jak liczby będą wyświetlane w Twoim modelu danych – system bazy danych będzie obsługiwał przechowywanie liczb dziesiętnych, a Twoja aplikacja powinna dostosować się do sposobu wyświetlania liczb dziesiętnych („.” lub „”, jako dziesiętne punkt, na przykład). Podobnie, nie musisz się martwić, jakiego separatora tysięcy (takiego jak kropka lub przecinek) użyje Twój model danych.
Oto sedno: Wybierz poprawnie typy danych podczas modelowania. Twoja aplikacja powinna obsługiwać formatowanie danych wyjściowych.
Na przykład w tym prostym modelu aplikacji stacji pogodowej pomiary pogody (temperatura, wilgotność, opady) są przechowywane jako liczby zmiennoprzecinkowe. Ale informacje o cenie są podawane w postaci dziesiętnej, podobnie jak współrzędne GPS każdej stacji pogodowej.
2. Waluty i kursy wymiany
Jeśli przechowujesz informacje związane z walutami, musisz przechowywać poprawną liczbę miejsc dziesiętnych dla każdej waluty. Większość walut ma dwa miejsca po przecinku, ale niektóre nie mają żadnego (np. chilijskie peso), jednego (ariar malgaski), trzy (dinar tunezyjski) lub nawet cztery miejsca po przecinku (Chile Unidad de Fomento, jednostka rozliczeniowa używana do wyrażania zakres wartości cen.)
Dlatego upewnij się, że pola „kwota” w modelu danych obsługują więcej niż dwa miejsca po przecinku – chociaż cztery miejsca po przecinku są bardzo rzadkie, to się zdarza. Częściej występują trzy miejsca po przecinku. Na przykład dinary w sześciu różnych krajach (Bahrajn, Irak, Jordania, Kuwejt, Libia, Tunezja) i rial w jednym kraju (Oman) wymagają trzech miejsc po przecinku.
Punkt nr 1: Wybierz prawidłowo typ danych podczas modelowania.
Kolejnym ważnym punktem związanym z walutami są kursy walut. Wymagają one jeszcze większej precyzji. Wiele systemów podaje tylko 4-6 cyfr znaczących w kursach wymiany; czasami istnieje czynnik skalujący między walutami, które mają bardzo różne wartości. Jednak cztery lub sześć cyfr znaczących niekoniecznie oznacza, że będzie sześć miejsc po przecinku. Sprawdź kurs wymiany rupii indonezyjskiej na euro:0,0000668755. To dużo miejsc po przecinku do przechowywania w polu kursu wymiany.
Punkt nr 2: Twój model może wymagać obsługi wysokiego poziomu precyzji – wielu miejsc po przecinku – jeśli chodzi o kursy wymiany.
Poniżej stworzyliśmy przykładowy sklep internetowy z cenami. Dodaliśmy również prostą tabelę (podświetloną w kolorze aqua), w której przechowywane są kursy wymiany walut, w tym historyczne kursy wymiany. Każdy wiersz w exchange_rate tabela jest połączona z walutą (currency_id , który jest kodem waluty ISO 4217). Zezwalamy na przechowywanie jednego kursu wymiany dla każdej waluty w określonym dniu (rate_date ) i mieć jeden aktywny kurs wymiany dla każdej waluty.
Oczywiście będziesz potrzebować dodatkowych informacji, aby skorzystać z tej tabeli stawek. Na przykład, w stosunku do jakiej waluty bazowej są zdefiniowane te kursy wymiany? Euro lub dolary amerykańskie mogą być typowe, ale Twoja aplikacja wymaga tutaj dokładnych informacji.
Alternatywnie, bardziej złożony model może przechowywać pary walutowe, kurs średni (lub kurs bankowy) oraz kursy kupna i sprzedaży pomiędzy tymi parami walut.
Punkt nr 3: Twój model musi mieć wystarczającą ilość informacji, aby aplikacja mogła prawidłowo wykorzystać dane.
3. Numery telefonów
Często widziałem systemy, które obsługują tylko dziesięciocyfrowy numer telefonu w Ameryce Północnej z trzycyfrowym numerem kierunkowym, trzycyfrową centralą i czterocyfrowym numerem abonenta (tj. 012-345-6789). To nastawienie jest do pewnego stopnia zrozumiałe; ludzie tworzą systemy wspierające ich lokalnych użytkowników. Modelowanie danych nie powinno jednak ignorować możliwości, że użytkownicy globalni mogą uzyskać dostęp do systemu. (Uwaga:dziesięciocyfrowa długość może być również użyta w przypadku innych numerów, takich jak francuskie telefony komórkowe, ale format jest inny (np. 06 12 34 56 78).)
Weźmy to jako przykład:załóżmy, że mieszkam tuż za granicą francuską, ale pracuję we Francji. W związku z tym, chociaż mogę potrzebować korzystać z francuskich aplikacji i usługodawców, mój numer telefonu komórkowego nie jest numerem francuskim. Systemy wymagające dziesięciocyfrowego numeru telefonu komórkowego zaczynającego się od 06 lub 07 nie będą dla mnie działać. Aby dostać francuskie bilety kolejowe, kupić bilety na koncert we Francji (itd. itp.), musiałbym zdobyć francuski numer telefonu. Co najmniej uciążliwe.
Oto sedno: Gdy ograniczenia dotyczące numeru telefonu są wbudowane w model danych, modyfikacje modelu danych będą wymagane do obsługi użytkowników nielokalnych. Idealnie, model powinien mieć wystarczającą elastyczność, aby poradzić sobie ze wszystkimi ewentualnościami.
Bardziej logiczny model danych obsługiwałby numery telefonów o różnej długości (do 16 cyfr w niektórych obszarach) i znaki nienumeryczne (takie jak uniwersalny symbol „+” dla międzynarodowego numeru telefonu). Z pewnością niektóre aplikacje mogą przeprowadzać większą walidację, wdrażając „lokalne reguły”, z którymi lokalni programiści byliby bardziej zaznajomieni. Inne aplikacje mogą używać lokalnych numerów telefonów do uzyskiwania dostępu do innych źródeł danych, takich jak weryfikacja lub pobieranie adresu na podstawie numeru telefonu.
Model danych powinien wspierać elastyczność w przechowywaniu informacji. Aplikacja lub jej interfejs użytkownika mogą być bardziej restrykcyjne lub wykonywać dodatkową weryfikację.
4. Adresy
Jako Amerykanin mieszkający za granicą często znajduję przykłady modeli danych i wzorce, które są zbyt amerocentryczne. Na przykład osoba spoza Ameryki może nie rozumieć, co oznacza Zip+4 jest i dlatego nie miałby pojęcia, dlaczego autor twierdzi, że ta domena musi mieć charakterystykę NOT NULL.
Ten amerocentryczny pogląd jest obecny nawet w książkach. Weźmy na przykład dość obszerną książkę „Wzorce modeli danych. Konwencje myśli” Davida C. Hay. Bardzo złożone wyjaśnienie adresów, miejsc, lokalizacji geograficznych, działek i elementów struktury geograficznej, które przedstawił pan Hay, zawierało przykłady z Kanady, ale mimo to informacje te mogą nie być łatwo zrozumiałe dla wszystkich.
Wzorce pana Hay mówią, że atrybuty adresu będą obejmować:
„Tekst” adresu oraz co najmniej „miasto”, „stan” i „kod pocztowy (ZIP)”.
Teraz pan Hay szybko wyjaśnia w przypisie, że:
Kontekst modelu określi, czy ten atrybut to „kod pocztowy”, czy „kod pocztowy”. Jeżeli w dającej się przewidzieć przyszłości organizacja klienta będzie działać wyłącznie na terenie Stanów Zjednoczonych, można przyjąć dziewięciocyfrowy, dwuczęściowy numeryczny „kod pocztowy”. Jeśli nie, „kod pocztowy” musi stać się „kodem pocztowym” i żadne założenia dotyczące formatowania nie są możliwe.
Nie wspomina jednak, że „stan” może być stanem w USA, prowincją w Kanadzie lub atrybutem dopuszczającym wartość null dla prawie każdego innego kraju, ponieważ „stany” w krajach rzadko istnieją poza USA, Kanadą (gdzie są nazywane są prowincjami, ale funkcjonują podobnie) i Australią. Oczywiście w innych krajach są prowincje i regiony, ale rzadko są one używane jako część adresu.
Aby zilustrować, jak poważny może być ten problem z adresem, stworzyłem model danych zarówno dla adresów amerykańskich, jak i nieamerykańskich. (Uwaga:to nie jest kompletny model).
PrimaryPhone US_Customer tabela przechowuje tylko numery telefonów zawierające dziesięć lub mniej znaków. Międzynarodowy projekt Customer PrimaryPhone tabeli Atrybut umożliwia podanie numeru telefonu składającego się z 15 cyfr plus „+”, co jest wartością maksymalną określoną przez E.164.
TimeOffset atrybut w US_Customer Tabela zezwala tylko na cztery strefy czasowe:czas wschodni, czas środkowy, czas górski i czas pacyficzny (przechowywane w modelu danych jako:0 =wschodni, 1 =środkowy, 2 =górski, 3 =pacyficzny). Nawiasem mówiąc, nie obejmuje to nawet wszystkich stref czasowych w USA i na ich terytoriach. Natomiast Timezone atrybut w Customer tabela przechowuje międzynarodowy kod strefy czasowej klienta, niezależnie od tego, gdzie się znajduje.
Następnie spójrzmy na kod pocztowy / pocztowy. Stany Zjednoczone wymagają 5-cyfrowego kodu pocztowego (Zip US_Address tabeli) plus opcjonalny ZIP+4 (Zip4 US_Address stół). Address tabela ma bardziej elastyczny PostCode pole. Poza długością nie ma ograniczeń co do informacji, które mogą być przechowywane w PostCode; oczywiście aplikacja może wdrożyć kontrolę kodów pocztowych.
Zwróć również uwagę, że zarówno projekty amerykańskie, jak i inne, mają pole dla regionów w kraju (State w US_Address table i Region w Address tabeli), ale projekt w USA wymaga uwzględnienia dwuznakowego skrótu stanu. Zwróć też uwagę, że projekt amerykański nie akceptuje adresów międzynarodowych, podczas gdy wersja adresu międzynarodowego tak (stąd dwuznakowy kod kraju ISO Kraj Address tabeli).
Oto sedno: Nie ograniczaj swojego modelu danych adresów do jednej miejscowości; zostaw wystarczająco dużo miejsca na różne style.
5. Formatowanie daty i godziny
Modele danych nie powinny dotyczyć wielu formatów daty i czasu; aplikacja obsługuje rzeczywisty wyświetlacz. Można to zrobić na różne sposoby:
- Styl pierwszego miesiąca, powszechny w Ameryce Północnej i innych krajach:mm-dd-rrrr
- Styl pierwszego dnia, który jest bardziej popularny w Europie:dd-mm-rrrr
- Styl pierwszego roku używany jako format daty ISO 8601:rrrr-mm-dd
Oto sedno: Może się to powtarzać, ale powtórzymy to jeszcze raz:podczas modelowania wybieraj poprawnie typy danych. Ułatwi to kodowi aplikacji interpretację i wyświetlanie przechowywanych wartości.
Kolejna pozycja w tej kategorii może być nieco nieoczekiwana:w którym dniu zaczyna się tydzień. Dla niektórych jest to niedziela; dla innych jest to poniedziałek (a potem jest kalendarz perski, który zaczyna tydzień w sobotę).
Czasy muszą być również wyświetlane w sposób przyjazny dla użytkownika. Pamiętaj, że chociaż Twój model danych nie wymaga wielu formatów czasu, możesz przechowywać preferencje czasowe użytkownika , czyli format 12- lub 24-godzinny.
To prowadzi nas do stref czasowych.
6. Strefy czasowe
Nie jest niczym niezwykłym znalezienie aplikacji, które pozwalają użytkownikom na wybór tylko kilku stref czasowych:czasu wschodniego, czasu centralnego, czasu górskiego i czasu pacyficznego. Kiedy to widzę, wiem, że mam do czynienia z Amero-centrycznym projektantem aplikacji. Niektórzy projektanci pozwalają, aby strefa czasowa była wyrażana jako przesunięcie od (zwykle) GMT lub UTC. Jednak wielu popełnia błąd zezwalając tylko na przesunięcia liczb całkowitych, nie zdając sobie sprawy, że niektóre kraje (Indie, Iran, Pakistan, Afganistan i inne) nie są przesunięciami całkowitymi. Są trochę inne:czas standardowy Indii to UTC+5:30. Niektóre lokalizacje mają nawet mniejsze ułamkowe przesunięcie, takie jak Nepal Standard Time – to UTC+05:45.
Jakiś czas temu pisałem o modelu do internetowej bazy ankiet. Tutaj dodałem strefę czasową do tabeli użytkowników, dzięki czemu możemy wyświetlać daty/godziny w czasie lokalnym użytkowników.
Więcej informacji o datach, godzinach i strefach czasowych można znaleźć w standardowej reprezentacji dat i godzin ISO 8601 lub w tym artykule w Wikipedii.
Oto sedno: Naucz się myśleć globalnie, nie tylko lokalnie.
7. Wsparcie wielojęzyczne
Wiele razy Twoja aplikacja może wymagać obsługi wielojęzycznej. Z perspektywy modelu danych może być konieczne przechowywanie informacji w wielu językach; jednak większość obsługi językowej powinna być uwzględniona w aplikacji. Wdrożenie obsługi wielojęzycznej wykracza poza zakres tego artykułu, ale omówiliśmy to już na tym blogu.
Lokalizacja jest bardzo ważna i należy ją odpowiednio obsługiwać. Jak już wspomnieliśmy, oznacza to coś więcej niż tylko wspieranie różnych języków; chodzi również o preferowane formaty dat, godzin, walut, a nawet wskaźników dziesiętnych.
Modelowanie danych? Myśl globalnie
Tworząc swój model danych, rozważ potencjalne międzynarodowe wykorzystanie Twojej aplikacji i jej bazy danych. Myśl globalnie w fazie projektowania, a unikniesz później pewnych problemów – pole numeru telefonu, które akceptuje tylko 3 cyfry + 3 cyfry + 4 cyfry, działa dobrze w USA, ale nie tak dobrze w Chinach czy Indiach.
Czy Twoje bazy danych są przygotowane do globalizacji? Twoim celem powinno być umożliwienie elastyczności bez tworzenia przytłaczającej złożoności.
