Електронните таблици – Excel, Google Sheets или лист с друго име – са наистина страхотни и мощни инструменти. Но също така и базите данни. Кога трябва да се придържате към електронна таблица? Кога трябва да преминете към база данни?
Това е продължението на предишната ми статия „Електронни таблици срещу бази данни:Време ли е за превключване?“ където обсъдихме най-често срещаните недостатъци при използването на електронни таблици за организиране на много данни. В тази статия ще разберем как една база данни решава тези проблеми.
Използване на база данни за организиране на данни
Мотото ми е „използвайте подходящата технология за вашите нужди“. Ако можете да управлявате бизнеса си чрез листове, страхотно! Ако имате нужда от проста база данни, MS Access не е лош вариант. Но ако тези продукти не работят за вас, вероятно ще имате нужда от персонализирана база данни и уеб приложение. Базата данни ще съхранява вашите данни; уеб приложението ще бъде удобен за потребителя начин за взаимодействие с базата данни и комуникация със слоя данни.
Фиктивният ни бизнес с услуги не беше много сложен, така че можехме да го захранваме с помощта на доста прост модел на данни. Ако погледнете изображението по-долу, ще видите, че всичко, от което се нуждаем, се съхранява само в пет таблици:client_type , client , service , replacement и has_service .
Ключово правило при проектирането на база данни е да съхранявате свързани данни от реалния свят на едно място . В този случай ще запазим всичките си client данни в клиентската таблица. По този начин ще избегнем съхраняването на едни и същи данни на множество места (лошият вид излишък, споменат по-рано). Ако променим нещо, свързано с клиент, ще го направим само веднъж, в тази таблица. Това значително ще подобри качеството на данните и ще бъде добро за производителността.
Следващата таблица, която съдържа реални данни, е service маса. Отново можем да съхраняваме всички подробности, свързани с нашите услуги тук, и можем да правим промени в данните доста ефективно.
client таблицата и service таблицата са обекти от реалния свят, които биха могли да съществуват без другия. Създаването на база данни с несвързани обекти обаче няма особен смисъл – това е като да имате клиенти без продукти или услуги без купувачи. Така че ще свържем тези две таблици с помощта на has_service маса. За да съхраняваме информация кои клиенти имат коя услуга, ще използваме външни ключове, които действат като препратки към този клиент и услуга. Тези външни ключове сочат обратно към записи в таблиците на услугите и клиентите. В тази таблица можем също да запазим всяка допълнителна информация, свързана с всяка връзка клиент-обслужване.
client_type таблицата се използва като речник, който съхранява всеки възможен тип клиент. Най-добре е да запазите различни сегментации в отделни речникови таблици (например, ако имахме типове клиенти и типове роли на служителите, бихме ги съхранявали в различни таблици). Нуждаем се обаче само от една таблица, защото това е прост модел.
Последната таблица в нашия модел е replacement маса. Ще го използваме, за да свържем две услуги:услуга, която искаме да заменим, и услуга за подмяна. Това ни дава гъвкавостта да предлагаме на клиентите заместители на съществуващи услуги (подобно на преминаване от един план за мобилни обаждания към друг).
Предимства на базата данни
Базите данни са по-сложни за настройка от електронните таблици, но това всъщност им дава някои значителни предимства по отношение на целостта и сигурността на данните:
Ключове и ограничения
Базите данни имат вградени правила и контроли, които, ако се използват правилно, ще предотвратят повечето проблеми с качеството на данните и производителността. Първичните ключове (колони, които уникално идентифицират всеки запис в таблица) и външни ключове (колони, които се отнасят до запис в друга таблица) са от решаващо значение за безопасността на данните, но определят алтернативни или УНИКАЛНИ ключове (които съдържат данни, уникални за всеки запис в таблица ) също е много полезен.
В релационните бази данни ключовете свързват данни от различни таблици. Първичният ключ на таблицата винаги е УНИКАЛЕН, докато външният ключ препраща към първичния ключ от друга таблица. Тази препратка свързва данни от тези две таблици (напр. външните ключове в has_service таблица свързва клиентските данни с услугите, които имат). Той също така ще ни предупреди, ако се каним да изтрием първичен ключ, посочен в друга таблица. Това ще ни попречи да изтрием записи, които все още са необходими (като препратки) в друга таблица.
Ограниченията определят вида данни, които могат да бъдат въведени в поле. Можем да посочим, че данните трябва да имат стойност (НЕ NULL), да дефинираме формат за телефонни номера, да съдържат само букви и т.н. Това означава, че можем да избегнем проблеми с данните от хора, които въвеждат грешен тип данни в поле.
Сигурност и разрешения
Друга много важна функция на базата данни е контрол на достъпа до вашите данни . Това ви дава възможност да зададете не само кой има достъп до вашата база данни, но и да контролирате какво може да вижда или променя. Това е огромна част от сигурността на данните. Например, можете да дефинирате потребителска роля, която ще позволи на служител да променя данните за клиента, но не и подробностите за услугата. Можете също да зададете правила, за които служителите могат да променят или изтриват данни. Добра стандартна практика е да се гарантира, че хората имат достъп само до данните, които са им необходими, за да вършат работата си.
Разбира се, бихме могли да опитаме да пресъздадем тези функции в листове (поне по някакъв начин), но това определено би било „преоткриване на колелото“.
Не бихме ли могли просто да използваме електронна таблица?
Разбира се, че бихме могли. Бихме могли да създадем листове, които следват същия модел, използван в модела на данни. Това би разрешило много проблеми с данните, но...
Възпроизвеждането на модела на данни в листове определено не е идеален вариант. Ще загубим всички предимства, които системата ни предоставя, всички правила и ограничения, които поддържат данните „здрави“, всички неща, които предотвратяват случайни изтривания и други грешки. Щяхме да загубим от оптимизацията и, ако наборът от данни беше достатъчно голям, производителността щеше да бъде ударена.
Дори и да решим това, какво ще кажете за споделянето на данни, напр. като няколко потребители използват един и същ лист по едно и също време? Какви проблеми с целостта на данните и производителността би причинило това? Това би било обратното на опростяване на нещата.
Така че, ако смятате, че листовете не могат да се справят с вашите бизнес нужди, вероятно вече сте се насочили към база данни. Ако се окажете блокирани с данни, съхранявани в листове, и искате да преминете към база данни, трябва:
- Създайте модел на база данни, който съхранява вашите данни оптимално.
- Създайте приложение с базата данни във фонов режим.
- Изчистете данните си, трансформирайте ги (ако е необходимо) и ги импортирайте в базата данни.
- Продължете да работите само с базата данни.
Кое да изберете – електронна таблица или база данни?
В днешната статия научихме как една база данни решава проблеми с използването на листове за организиране на много данни. Моят съвет е винаги да се придържате към най-простото решение на вашия проблем . Ако електронните таблици ще свършат работата правилно, използвайте ги. Но ако сте компания, управлявана от данни, трябва да започнете да използвате база данни възможно най-скоро. Колкото по-дълго чакате да почистите и мигрирате данните си, толкова по-болезнен ще бъде процесът.
