Мекен-жай мәліметтерін бөлек дерекқор кестесіне шығару керек пе?

Менде «Тұлға» деп аталатын үстел бар, келесі өрістер бар

  • Id (негізгі кілт)
  • Бірінші Name
  • LastName
  • DateOfBirth
  • Қала
  • Мемлекет
  • Ел

Қала, мемлекет немесе ел сияқты нәрселер қалыпты жағдайға келтірілсе және өздерінің кестелеріне бөлінсе, онда осы кестеде CityId және StateId бағалары бар. Біз бұл жақсы немесе жаман шешім болып табыла ма деп пікірталасып жатырмыз.

Қосу үшін менде қала мен мемлекеттің кестесі бар (бұл адам кестесіне қатысы жоқ басқа себептер бойынша). Мен бұл қосымша факті бар немесе онсыз жауаптым.

19
@Alexander Jardim - мүлдем келісемін. . мәселе біз қарастырмаған және келешекте өртелетін кез-келген нүктелердің пайда болуын болдырмау болды. . Басқа адамдармен жұмыс істеудің бұрынғы мысалдары өте пайдалы
қосылды автор leora, көзі
Менің ойымша, бәрі сіздің пайдалану жағдайыңызға байланысты. Қалыптасқан кезде дизайн шешімі толығымен. Менің ойымша, сіздің командаңыз сізге не қажет екенін білуге ​​және үстелге сіздің қосымшаңыздың дизайнын қалыпқа келтіретіндігіне ешкім сенбейді деп ойлаймын. Жай ғана айтқаным жөн, немесе маған дұрыс емес деп ойлаймын.
қосылды автор Alexander Jardim, көзі
қосылды автор WW., көзі
Көргенімнің біреуі - қайталану. Егер сіз кампуста көптеген адамдармен қарым-қатынас жасасаңыз, олардың әрқайсысы көптеген бөлмелері бар өте аз ғимараттар болуы мүмкін. Fortune 500 клиенттің тізімі қайталанатын мекенжайлармен (сату, есеп, R & D, ...) көптеген байланыстарға ие болуы мүмкін. Мұндай жағдайларда «белгілі» көше мекенжайларының тізімін ұсынуға және пайдаланушыларға қажет болған жағдайда жаңаларын қосуға мүмкіндік береді. Бөлме, бөлім, «назар», ..., әрбір Person үшін өзгереді. Мәселе, мысалы, химия Химиялық инженериядан бөлек жаңа ғимаратқа ие болғанда пайда болады. Сіз кімнің қозғалуын қалай білесіз?
қосылды автор HABO, көзі

10 жауаптар

Мекенжайды иерархияға қалыпқа келтіру - күмәнді ұсыныс. Бұл сіздің мекен-жайыңыздағы деректермен не істеу керектігіне байланысты.

Жаңылыстың ауытқуын болдырмау үшін қалыпқа келтіру идеясы сәл шүбәсіз. Қалалар, штаттар немесе елдер қаншалықты жиі аттарды өзгертеді? Бұған қоса, егер бұл жағдай орын алса, өзгеріс көтерме бола ма? (Яғни, ескі есімнің әр данасы Y жаңа атауына өзгереді). Мен 2000-шы жылдардағы муниципальдық бірлестіктердің қайнар көзі болғанда, Канадада іс жүзінде не болғанын айтып бере аламын, солардың шекаралары жаңартылып, ескі атаулардың көбісі, бұрынғыға қарағанда, аз аумаққа ие болды.

Муниципалдық атаулар сияқты нәрселер еркін түрде анықталуы мүмкін. Мысалы, мен өскен жерімде менің почта жөнелтімінде пошта әкімшілігінің ресми түрде танылған үш ресми атауы бар еді: УОДОДАЛЕ, Солтүстік Йорк, Торонто - олардың барлығы жарамды нұсқа болғанымен, біреуі басқаларға қарағанда «ресми» болды. Мәселе мынада, бұл барлық Willowdale Солтүстік Йоркте, бірақ Солтүстік Йорк-ақ бар «Downsview» және басқалар.

Мекен-жайларды қалыпқа келтіретін басқа жиі дәлелдер мыналарды қамтиды: дұрыс жазуды қамтамасыз ету және аумақты басқару үшін негіз беру. Мекен-жай деректерінің сапасының бұзылуын ескере отырып, бұл дәлелдер сенімді емес.

The best way to ensure address data quality is to keep your addresses in a relatively flat, relatively simple structure and to employ one or more address quality tools that use postal authority data to match and standardize your addresses. Keep city, state and postal code in their own fields, by all means, but don't keep them in distinct tables. This is actually more flexible than a normalized structure while producing more reliable results overall.

Сол сияқты, аумақты басқару жақсы муниципалитетке қарағанда неғұрлым түйіршіктелген деңгейде жүзеге асады. Кейбір муниципалитеттер өте үлкен және атаулары бірдей болуы мүмкін. Оның орнына пошталық индексті немесе ZIP + 4 (юрисдикцияға байланысты) пайдаланыңыз. Бұл әлдеқайда түйіршікті және айқын. Мекен-жайдың деректер сапасының құралы сіздің мекенжайларыңызда тиісті пошталық кодтауды қамтамасыз етеді.

21
қосылды
@DavidAldridge - интернационалдандыру, қолданбаға байланысты қызыл майшабақ болуы мүмкін. Біреудің мекенжайы - пошта немесе сәлемдемелерді алатын тілде олардың мекен-жайы. Екінші жағынан, егер сіз аумақтарды басқа мақсаттармен қадағалап отырсаңыз, онда олар адреске тәуелсіз және иерархияда болуы керек, егер бұл мағынасы болса, бірақ іргетасы пошта коды сияқты түйіршік болуы керек, егер ол болмаса геокодтауға қатаң негізделген. Geocoding бағдарламалық қамтамасыз ету қазіргі уақытта географиялық полигондармен анықталуы мүмкін аумақтарды жетілдіреді және мекен-жайы мүлдем қалмауы мүмкін.
қосылды автор Joel Brown, көзі
Менің ойымша, бұл құлдыраудың бір саласы - интернационалдандыру. Егер сізде жүйе үшін халықаралық пайдаланушы базасы болса, онда сіз «Мюнхен» (неміс), «Мюнхен» (француз), «Мюнхен» (испан), «Monaco di Baviera» Итальян тілінде), «Munique» (португал тілінде) және т.б. Егер Сізге Қиыр Шығыстың қалаларының атауларын қосу қажет болса, сізге ана тілін және таңбалар мекен-жайын, сондай-ақ латын нұсқаларын қажет етуіңіз мүмкін.
қосылды автор David Aldridge, көзі
Бұл көптеген жүйелердің шатастырылуы керек аймақ, бірақ мен, әрине, осы типті қалыпқа келтіру қажет болатын халықаралық деректер жинақтарымен жұмыс істедім. Мен «қызыл майшабақ», көп «маман» деп айтпадым.
қосылды автор David Aldridge, көзі
Tut, мен мынаны былай қойдым: «Бұл емес көптеген жүйе ...»
қосылды автор David Aldridge, көзі
Өте жақсы жауап. Егер сіз мекенжайларға иерархияны сақтауды аяқтасаңыз, онда барлық пайдаланушылардың мекен-жайларын жаңарту, сақтау және тексерудің ауыртпалығын көтеруге тура келеді, ол қазіргі уақытта қандай-да бір қолданушы қазірдің өзінде екі елге бөлінгенде, және пайдаланушыны өз қалауы бойынша өз мекенжайларын жаңарту бостандығын беру үшін түзетеді.
қосылды автор Subhas, көзі

Менің тәжірибемнен, иә.

1 Қала, мемлекет және ел - бұл нақты әлемдегі ұйымдар, сондықтан сіздің деректер базаңыздың үлгісінде ұйым болу керек. Басқа жауап берушілер айтқандай, бұл атаулардың дәйектілігін сақтайды

2 Сіз оларды толтырып, сыртқы ашық көздерден немесе стандарттау органдарынан тексере аласыз. Мысалы, елдер үшін ISO3166 халықаралық стандарт болып табылады

3 Қолданбаңыздың сіздің қазіргі немесе болашақ нұсқаларыңызда оларды сақтау үшін сыртқы көздерден тікелей қосылуға болады.

4 Көптеген тілде сөйлейтін болсаңыз, бәрін бір жерде аударуға болатын есімдерге ие боласыз

5 Егер сіз кез-келген уақытта басқа тараптармен немесе қолданбалармен деректер алмассаңыз немесе интерфейс жасасаңыз, сізге ортақ классификация қажет болады

8
қосылды
+1: Ия, Джоэлдің жауабына түсініктемеде айтқанымдай. Мекенжайлық элементтерді i18n-ні жоюға болмайды, егер олар denormalised болса
қосылды автор David Aldridge, көзі

Мен бастамас бұрын, (қаланың, мемлекеттің, елдің) мекен-жайы жоқ екендігін атап өткім келеді.

Қала, мемлекет немесе ел сияқты нәрселер қалыпты және сынған болуы керек   өз столына қояды, содан кейін осы кестеде CityId және StateId бар   бағандар. Біз бұл жақсы немесе нашар болғаны туралы пікірсайыс өткіздік   шешім.

Нормализация жақсы. Мен қалыпты жағдайға әрдайым қолдау көрсетемін.

Бірақ мәтіннің орнына ID нөмірлерін пайдалану қалыпты жағдайға байланысты ештеңе жоқ болады. «City» және «StateId» «State» үшін «CityId» дегенді ауыстыру кестенің қалыпты түріне әсер етпейді. Егер бұл өзгеріс алдында 3NF болса, ол сол өзгерістен кейін 3NF болады.

деректер тұтастығын мәнін сыртқы кілт сілтемесімен бірге арттыруға болады. Деректердің тұтастығы да жақсы. Бірақ бұл, көптеген басқа да дерекқорды жобалау шешімдері сияқты, қалыпқа келтіруге ешқандай қатысы жоқ.

Қалалардың деректер тұтастығын жоғарылатудың ең қарапайым жолы - жаңа қалаға нақты қалаларды таңдау. (PostgreSQL синтаксисі.)

select distinct city, state, country
into new_table
from person;

Қаланың «толық аты» дегенді білдіретін қала, мемлекет және ел қажет. Сізге кілт керек.

alter table new_table
add primary key (city, state, country);

Енді сіз (қала, мемлекет, ел) әрқашан осы жаңа кестеде бір жолға сілтеме беретініне кепілдік беру үшін шетелдік кілт шектеулерін жариялай аласыз.

alter table Person
add constraint city_state_country_from_new_table
foreign key (city, state, country)
references new_table (city, state, country)
on update cascade;

Мен кестенің осы түрі үшін каскадты жаңартулардың орындалуына алаңдамаймын. (Oracle пайдаланбасам, Oracle каскадты жаңартуларды қолдамайды). Бұл атаулардың түрлері сирек өзгереді және PostgreSQL жаңартуларын менің үстелімде 3 секундтан аз 50 миллион жолдар кестесінде 3 миллион жолға дейін жаңарта алады. Менің жұмыс үстелім ерекше ештеңе емес және ол 3 дерекқорды басқару жүйелері мен екі веб-серверлерді басқарады. Егер менде үлкен кестелер болса және көп уақыт қажет болса, техникалық қызмет көрсету терезесінде өзгертуді жоспарлаймын.

Деректер тұтастығын дәл осылай етіп көбейте аласыз.

select distinct state, country
into another_new_table
from new_table;
etc., etc.

Мұның бәрін айта отырып, new_table-ге суррогат кілтін қосу - бұл дизайнды шешуге арналған шешім, бірақ бұл туралы ойлануға уақыт бөлсеңіз ғана. (Ойланбайды, ешқашан қорғалмайды.)

{Қаланы, мемлекетті, елді) суррогат кілтімен ауыстырудың ең тез әсер етуі, сіз енді no талап етілетін кестеде әрбір сұрауда қосылу қажет. Сіз әсерді кездейсоқ үлгілік деректермен өнімділікті тексере аласыз. Сізде миллиондаған жолдар болғанша, табиғи кілт суррогат кілтіне қосылудан жылдамырақ екенін көресіз. Мен сынаған кезде таптым.

3
қосылды

Иә, әрине. Егер ел немесе қала аты өзгертсе, оны бір жерде өзгертесіз және барлық сілтемелер автоматты түрде жаңартылады.

Бөлу, сондай-ақ, елге немесе қалаға басқа атрибуттар қосуға мүмкіндік береді, яғни континентте және т.б.

Соңында, егер тізім тізімін жасау керек болса (мысалы, тізім терезесін толтыру үшін) сізде сілтеме жасау үшін бір орын бар. (Әйтпесе, сіз адам кестесінен кейбір ТЕКСЕРЛІК КӨРСЕТУ жасайсыз, ол күмәнді болып табылады.)

2
қосылды

Мен қаланы, мемлекетті және елді бөліп, жолдар арқылы қайталанған мемлекет пен елді қамтитын бірыңғай «мекен-жай (немесе қала)» кестесіне шығаруды қарастырамын. Әлемдегі бірегей қалалардың саны үшін бұл нақты дерекқордың сұрау құны емес.

Бұл сондай-ақ, сіз үміттегі жазбалар санына байланысты болады - егер жалпы адам санағы әрдайым 100,000 дейтін болса, онда деректерді қалыпқа келтіруге күш салу керек пе?

Тегіс деректер құрылымы бар болса, сұраулар мен тестілеуді әлдеқайда қарапайым етеді, сондықтан өнімділік немесе дискілік кеңістік проблемасы болмаса, онда «қарапайым сақтау» дұрыс.

2
қосылды

Бұл қалаға, мемлекет пен елге қайдан алынғандығына байланысты.

Егер сіздің қолданысыңыз пайдаланушыға осы ақпаратты енгізуге мүмкіндік берсе, бірақ оларды осы деректерді негізгі мәліметтеріңіз арқылы толтырылған ашылмалы таңбалардан таңдауға мәжбүрлейтін болса, онда осы үш өрісті «locationId» сияқты нәрсеге тастау және кесте бар (city_id, state_id, country_id) жазбаларын сақтайды. Сізге Адам кестесінде осы үш идентификатор қажет емес, себебі комбинация өте сирек өзгереді.

Керісінше, егер пайдаланушыларыңыз қала, мемлекет және ел үшін мәндерді енгізуге рұқсат берсе, онда сол қалаға/елге/елге арналған әртүрлі мәндеріне байланысты оларды бөлек кестеге бөлуге қиын болады.

1
қосылды
  • Егер бұл салыстырмалы түрде аз дерекқор болса және сіз пайдаланушыға мекен-жайын енгізуді жоспарлап отырсаңыз, кестені солай болуға тиіссіз.

  • Егер бұл салыстырмалы түрде үлкен дерекқор болса және пайдаланушы тізімнен қаланы, мемлекетті және елдің атауын таңдағыңыз келсе, онда сіз бұл бағандарды басқа кестеге бөліңіз. Сондай-ақ, бұл жұмыс істеу үшін осы кестені өзіңіз толтырыңыз. Пайдаланушылар мен мекенжайлар үшін артықшылықтар аз болады.

1
қосылды

Елге, мемлекетте, қалаға қатысты мәселе сілтеме жасалған кестеге үміткер кілті болу үшін көрінеді . SQL-де {country, state, city} мүмкін емес үміткер кілті (тіпті бастапқы кілт) болуы мүмкін if күйі (немесе ел) болмауы немесе NULL болуы мүмкін. (бұл NULL-ден басқа бос жолға рұқсат беру арқылы болдырмау керек еді, бірақ бұл нашар хэк, IMO). Сонымен қатар, елге . Және екеуі де жоғалып кетуі мүмкін, белгісіз немесе NULL.

Мүгедектігі бар үміткерлердің кілттері бойынша бірден-бір жол оларды (бірегей емес) индекстерге дейін төмендетіп, суррогаттың бастапқы кілтін қосады, мысалы:

CREATE TABLE cities
    ( city_id INTEGER NOT NULL PRIMARY KEY -- could be a serial ...
    , country_name varchar -- you _could_ squeeze this out into a separate "countries" table
    , state_name varchar   -- you could even squeeze this out, but it would need a composite FK
    , city_name varchar NOT NULL
    );

CREATE TABLE adresses
    ( person_id INTEGER NOT NULL PRIMARY KEY -- could be a serial
    , last_name varchar NOT NULL
    , first_first_name varchar
    , gender CHAR(1)
    , dob DATE
    , city_id INTEGER references cities(city_id) -- could be NOT NULL
    );

WRT {city, state}} : сіз осы сығып шығыңыз түйісу кестесіне (бұл негізінен BCNF мәселесі, тіпті 4NF мәселесі болса, NULLABLE емес) сияқты:

    --
    -- Plan B:
    --
CREATE TABLE country2
    ( country_id INTEGER NOT NULL PRIMARY KEY -- could be a serial ...
    , country_name varchar NOT NULL
    , country_iso varchar
    -- ...
    , UNIQUE (country_name)
    );

CREATE TABLE country_state2
    ( cs_id INTEGER NOT NULL PRIMARY KEY -- could be a serial ...
    , country_id INTEGER NOT NULL REFERENCES country2(country_id)
    , state_name varchar
    );
CREATE TABLE cities2
    ( city_id INTEGER NOT NULL PRIMARY KEY -- could be a serial ...
    , cs_id INTEGER REFERENCES country_state2(cs_id)
    , city_name varchar NOT NULL
    );

CREATE TABLE adresses2
    ( person_id INTEGER NOT NULL PRIMARY KEY -- could be a serial
    , last_name varchar NOT NULL
    , first_first_name varchar
    , gender CHAR(1)
    , dob DATE
    , city_id INTEGER references cities2(city_id) -- could be NOT NULL
    );

Шын мәнінде мұны істеу керек пе, дәм тату мәселесі (Джоэл Браунның жауапты қараңыз). Нормативтік-құқықтық реттеу, егер ОБ-да муниципалитеттердің бірігуі сияқты массивтік қайта аталуы мүмкін болса, сөзсіз көмектеседі. Кішігірім мекенжайлар жиынтығы үшін (бірнеше мыңға дейін), қосымша күрделілік, ол пайда болатыннан әлдеқайда қымбатқа түседі. Бұл күрделілік, деректерді сақтау үшін пайдаланылатын фронталдық қосымшалар үшін өте қымбат. ДББЖ үшін, бірнеше қосылыстар осындай үлкен мөлшерге (кішкентай өлшемдер үшін) шығын келтірмейді және тіпті өнімділікке (үлкен өлшемдер үшін) көмектесе алады. Нормалдау өнімділік үшін жаман емес.

UPDATE (Майк Шериллдің мысалынан кейін):

{Country, state, city} (немесе ids) мекенжайында NOT NULL шектеулерін қолдансаңыз, біз сондай-ақ UNIQUE шектеулерді (құрамдастырылған) кандидаттар кілттеріне енгізе аламыз:         -         - C жоспары:         -     TABLE country3 жасаңыз         (country_id INTEGER NOT NULL PRIMARY KEY - сериялы болуы мүмкін ...         , country_name varchar NOT NULL         , country_iso varchar         , UNIQUE (country_name)         );

CREATE TABLE country_state3
    ( cs_id INTEGER NOT NULL PRIMARY KEY -- could be a serial ...
    , country_id INTEGER NOT NULL REFERENCES country3(country_id)
    , state_name varchar NOT NULL
    , UNIQUE (country_id,state_name)
    );
CREATE TABLE cities3
    ( city_id INTEGER NOT NULL PRIMARY KEY -- could be a serial ...
    , cs_id INTEGER NOT NULL REFERENCES country_state3(cs_id)
    , city_name varchar NOT NULL
    , UNIQUE (cs_id,city_name)
    );

CREATE TABLE adresses3
    ( person_id INTEGER NOT NULL PRIMARY KEY -- could be a serial
    , last_name varchar NOT NULL
    , first_first_name varchar
    , gender CHAR(1)
    , dob DATE
            -- allowing NULL here allows for 'embryonic' records without city/state/country info.
    , city_id INTEGER references cities3(city_id)
    );

Бұл NOT NULL шектеуі {city, state, country} ішіндегі көшірмелерді болдырмаса да, олар импульс оларды НЕГІЗГЕ болмайды, анық. Бұл басқа елдерде (Канададан немесе АҚШ-тан басқа) мүмкін емес немесе жарамсыз болуы мүмкін. Нидерландыда state немесе county жоқ; provincie бар, ол қолданылмайды (қажет болған жағдайда ғана ажыратуға болады). departements үшін ұқсас, IIRC.

0
қосылды
Сіздің қалаңыз - суррогат кілті емес, бұл жасанды кілт. Суррогат, анықтамаға сәйкес, бір нәрсе орнын алады. Суррогат кілті қалаларыңыздың кестесі жоқ табиғи кілттің орнын алады. Бұл кестеңізді деректердің қайталануына мүмкіндік береді. Сізде «АҚШ», «CA», «Сан-Франциско» деген 30 жол бар. Менің тәжірибемде, қайталанатын деректерге рұқсат беру бұл шешімге қарағанда жиі қиындық туғызады.
қосылды автор Mike Sherrill 'Cat Recall&, көзі
Мен суррогат/артефитиялық анықтама туралы сенімді емеспін. WRT телнұсқалары: сіз дұрыссыз, бірақ бұл {cs_id} NULLable болуының тікелей салдары. Әйтпесе, cities2 үшін {cs_id, city_name} жүйесінде UNIQUE шектеуі қолданылуы мүмкін.
қосылды автор wildplasser, көзі

Меніңше, нормалдау деңгейі іс жүзінде қаншалықты үлкен болатынына байланысты. Кем дегенде, мекенжайлар кестесімен айналысатынмын, сондықтан CRUD мекенжайларында пайдаланушыларға қосылмай-ақ орындалуы мүмкін. Сіз қалалар мен штаттардың тізімін шығаруды немесе веб-қызметтерді ұсынатын UI жоспарлары бар болса, оны одан да көп сындырғыңыз келуі мүмкін. Шетелдік мекенжайларда фактор қажет болса және APO/FPO болса, біраз қиын болады. Википедия бетіндегі қалыпқа келтіру мақсаттары , сценарийлердің бар-жоғын білу үшін қажет болуы мүмкін жобаңызда ескерілуі тиіс. Деректерді немесе күш-жігерді жобалаудан тыс қайталамауға тырысыңыз.

Мен сіздің командамыздың ойлануы мүмкін қосымша ақпарат беруін қаладым:

Люк У. мекенжайларға UI жобалау туралы тамаша ақпарат бар.

Егер сіз веб арқылы орналастырсаңыз, орын туралы деректерді басқаратын көптеген веб-сервис API бар.

Егер деректер ішкі деңгейде сақталса немесе сіз сыртқы қызметтерге сенім артуды қаламасаңыз, ашық деректерді сияқты көздер сияқты GeoNames . Деректер қойындысы бөлінген мәтіндік файл болып табылады, бірақ деректерді автоматты түрде жүктеу үшін сценариймен оңай алынуы мүмкін.

0
қосылды

Мен «иә» деп едім, бірақ тек қана қала/мемлекет/ел үшін, егер сіз адамдарға аттарымен талдауды/топтауды жоспарламасаңыз.

Нәтижелерге, сондай-ақ, іздеу кестелеріндегі мәтін бағандарына арналған идентификатор бағандарында индекстер жасаңыз. Бұл пішіндерге арналған ашылмалы опцияларды оңай жасауға және деректер қорының өлшемі арта түскенде жылдам іздеу уақытына әкеледі.

Сонымен қатар, қысқа сандық индекс жазуы толық мәтіндік индексінен әлдеқайда жылдам, себебі қала/мемлекет/ел бағандарын индекстеп жатсаңыз, жазу жазу уақытын жылдамдатады.

0
қосылды