Когато пишете публикация в блог за моделиране на база данни, трябва да сте подготвени, че вашият абстрактен модел не отговаря на нуждите на повечето читатели. Причината е проста. Моделите на бази данни в реалния живот обикновено се създават в тясна връзка със специфични бизнес изисквания и изисквания за развитие, докато моделите на блогове не са.
През последните няколко седмици пиша публикации в блогове за създаване на модели на бази данни. Темите варираха от общ подход към моделирането на база данни през обикновен онлайн форум до модел за по-сложно онлайн проучване.
За всеки модел на база данни, който създавам, се опитвам да разбера ясно бизнес домейна и да изработя наум голямата картина на модела.
Предизвикателството на разработването на абстрактни бази данни
Обикновено, като решение архитект , приемам специфични бизнес изисквания и ги превръщам в технически подробности за това, което трябва да бъде създадено от техническа страна:превод от бизнес езика към техническия език – проектиране на алгоритмите на високо ниво и моделиране на изискванията за данни за алгоритмите.
За съжаление не мога да водя блог за моделите на бази данни от реалния свят, които създавам по време на работа. От една страна, те са много специфични за бизнес домейна, а от друга аз съм ограничен от споразумения за поверителност. За блога създавам чисто абстрактно концепция без специфични бизнес изисквания, освен тези, които си представям, че съществуват в рамките на бизнес домейна. Сега, това е добре; Имам доста добро въображение и често изтъквам, че вашите изисквания може да са различни, когато описвам изборите, които правя. Но този процес на блогване ме накара да се замисля колко различен е този процес от създаването на модели в реален проект.
Процесът на разработка в реалния живот
В реална ситуация бих работил в тясно сътрудничество с екипа за разработка, след като създам решение на високо ниво и технически дизайн в интерактивен начин, така че моделът да отговаря на нуждите за разработка.
Разработчиците може да се оплакват, че моделът на данните е твърде нормализиран, за да поддържа висока производителност, или може да поискат допълнителна нормализиране в определени области. Ако липсваха алтернативни ключове, разработчиците щяха да се оплакват доста бързо и ние също щяхме да го забележим по време на тестване на производителността на базата данни.
Ще разгледаме каква трябва да бъде точната дължина на полето въз основа на максималната дължина на данните, които трябва да се съхраняват, и на дизайна на екраните за въвеждане и показване на данните. Разбира се, точните дължини на полетата в концептуалния модел на база данни не са важни.
Ще работим с примери за това какви данни ще се съхраняват в таблиците и как ще бъдат използвани от приложението и ще създадем скриптове за предварително попълване на таблиците за тестване на модула на приложението. По този начин ще хванем ъгловите кутии, за да гарантираме, че моделът поддържа границите на приложението.
Така че, по принцип, ние ще масажираме модела, докато той наистина поддържа бизнес и нефункционалните изисквания на системата, използвайки итеративен процес, докато не развием модел в нещо, което всички можем да приемем въпреки компромисите, вградени в него.
Както казах, това ще бъде много итеративен процес, който може да продължи в продължение на много месеци, докато се разработват кодът на приложението, потребителските интерфейси и интерфейсите на приложението.
Ограничения на добронамерената обратна връзка
В настоящата ситуация с блогове, макар че моят действително ограничен брой читатели ми дава обратна връзка по въпроси и предизвикателства, които те наблюдават с моделите, това е задължително повърхностно. Съмнявам се някой от читателите да използва директно моделите, за да създаде приложение и да открие какво наистина работи и къде има проблеми.
Така че коментарите като „моделът не е добре обмислен“ почти със сигурност са правилни. От друга страна „липсват FK“ са доста точни, но се надявам, че съм обяснил в текста на статията защо включвам външен ключ или не.
Заключение
Сега, моля, не четете тази публикация като оплакване или коментар относно обратната връзка, която читателите правят, по-скоро разсъждавам върху трудността да се създаде модел на база данни, когато не сте в среда, която позволява интерактивен обмен с итерация процес на разработка.
Вероятно има и други ситуации, при които моделистите на бази данни са откъснати от процеса на разработка, но сега осъзнах колко опасно би било това и колко податливи на проблеми биха били те.
Можете ли да си представите модел на база данни, който никога не се променя? Никога еднократна корекция на колона, никога допълнителното на външен ключ, никога необходимостта от нова таблица. Честно казано, единствената ситуация, която мога да си представя така, е когато приложението, използващо базата данни, вече не се развива и е достигнало задънена улица:края на живота.
