sql >> Databáze >  >> RDS >> Database

Tabulky vs. databáze:Je čas přejít? Část 1

Tabulky – Excel, Tabulky Google nebo jiný list – jsou opravdu skvělé a výkonné nástroje. Ale to jsou i databáze. Kdy byste měli zůstat u tabulky? Kdy byste měli přejít na databázi?

Pro podobné účely můžete použít tabulky a databáze. Vzhledem k tomu, že jak organizovat data, tak usnadňovat hlášení, může být někdy těžké určit, který z nich je nejlepší použít. Pojďme si tedy promluvit o výhodách a nevýhodách každé možnosti.

Na začátku…

Pokud s podnikáním teprve začínáte, je téměř vždy vaší první volbou tabulka (nebo „list“). Startupy mají málokdy rozpočet na podporu vlastní databáze. A kromě toho je vaše podnikání nové; nebudete mít ponětí, jestli zůstane malý, stane se velkým korporací nebo bude někde uprostřed.

Dalším faktorem je, že struktura a organizace vašeho podnikání se pravděpodobně změní, jak roste. Takže vytvoření databáze na začátku není běžnou možností. Zde obvykle naskakují listy.

Nejdůležitějším důvodem pro použití listů je jejich dostupnost. Pomocí několika kliknutí můžete začít používat Microsoft Excel, Tabulky Google nebo jakýkoli jiný tabulkový procesor. Nemusíte plánovat složitou strukturu; můžete jednoduše zadávat svá data, provádět výpočty a sestavy a sdílet informace se spolupracovníky. Tabulky nabízejí mnoho skvělých vestavěných funkcí a dokážou malou firmu prozkoumat na poměrně dlouhou dobu.

Řekněme tedy, že máte všechna data na listech. Proč byste měli uvažovat o vytvoření databáze? Jinými slovy, proč si komplikovat život, když všechno funguje?

V tuto chvíli bych vám doporučil, abyste se zeptali sami sebe, jak dobře vše funguje. Pamatujte, že vše funguje dobře, dokud to nepřestane fungovat. V případě listů platí, že čím více dat máte, tím více problémů můžete narazit. Jak vám databáze pomáhají vyhnout se těmto problémům? A kdy byste měli uvažovat o přechodu?

Uspořádání dat pomocí tabulek

Předpokládejme, že jsme založili společnost, která zákazníkům poskytuje telekomunikační a internetové služby. Musíme sledovat, který zákazník si aktuálně předplácí kterou službu. Zákazníci mohou mít více než jednu aktivní službu najednou a služba může na konci nastaveného období vypršet nebo se automaticky obnovit.

Pojďme se podívat na řešení, které používá listy.

Jednoduše jsme vytvořili seznam všech dat, která máme, tj. je zde mix dat na jednom místě. Máme údaje o zákaznících (sloupce A až E), typy služeb (sloupec F) a podrobnosti o službách (sloupce G, H a J).

Na první pohled vše vypadá docela dobře. Můžeme prohlížet všechna data, aniž bychom museli provádět složité akce. Můžeme filtrovat data, která potřebujeme, a vytvářet kontingenční tabulky nebo grafy pro účely reportování. Zatím je to dobré.

Ale pokud budeme pokračovat v používání archů, když získáme více zákazníků, můžeme se dostat do bodu, kdy bude všechno příliš velké na to, aby to archy zvládaly. A to přináší nový soubor problémů.

Možné problémy s tabulkami

Oproti tabulkovým procesorům jsou databáze komplikované. Tyto „komplikace“ však slouží užitečnému účelu; předcházejí nebo alespoň minimalizují následující problémy:

Kvalita dat

Kvalita a konzistence dat je u větších listů obrovský problém. Přestože máme v úmyslu data ukládat správně, problémy s kvalitou dat jsou velmi časté. Lidé dělají chyby nebo musíme zadat neočekávané informace. Jen si představte, jak by níže uvedené scénáře mohly představovat problém:

  1. Chceme přidat nového zákazníka, aniž bychom uváděli typ jeho služby. Měli bychom přidat podrobnosti o zákazníkovi a vynechat podrobnosti o službě? Pokud můžeme vložit pouze zákazníky, kteří mají podrobnosti o službě, jedná se o anomálii vložení .
  2. Co když přidáme data služby, až budou k dispozici, po vytvoření záznamu zákazníka?
  3. Co když si zákazník předplatí více služeb? Měli bychom vytvořit nový záznam pro každou službu, protože můžeme mít pouze jeden typ služby na záznam?
  4. Co když máme více záznamů pro jednoho zákazníka a potřebujeme aktualizovat informace o tomto zákazníkovi? Pokud nezměníme informace ve všech příslušných řádcích, naše údaje budou nekonzistentní. Mohli bychom mít dvě různé adresy pro stejný účet; jak bychom za těchto okolností mohli vědět, která data jsou správná?
  5. Co se stane, když smažeme data? Pokud smažeme celý řádek, ztratíme všechna data tohoto zákazníka. To není dobrý nápad; je lepší odstranit pouze jejich servisní data a ponechat si jejich zákaznická data. Ale jak to můžeme udělat, když je vše uloženo v jedné řadě?
  6. Co když si službu předplatí pouze jeden zákazník a my tento záznam smažeme? Pokud smažeme záznam daného zákazníka, smažeme také všechny záznamy o této službě? (Tomu se říká anomálie odstranění .) Znamená to, že tuto službu již nenabízíme? Pokud ji stále nabízíme, ztratili jsme všechny parametry související s touto službou.

Je zřejmé, že při ukládání dat pro jakýkoli podnik nastanou komplikace. Všichni jsme byli na příjmu problémů s kvalitou dat – např. dostali jsme účty za služby, které jsme si neobjednali, byla nám dvakrát účtována stejná věc nebo jsme si nechali poslat balíček na špatnou adresu. Tyto věci se stávají a na malém datovém souboru je relativně snadné je opravit. Ale co se stane, když máme tisíce nebo dokonce miliony řádků? Brzy budeme téměř všechen svůj čas věnovat nápravě těchto problémů.

Problémy s výkonem

Problémy s výkonem dochází, když jsou datové sady příliš velké na to, aby s nimi list mohl efektivně pracovat. Problémy s kvalitou dat zaznamenáte mnohem dříve než problémy s výkonem, ale to neznamená, že problémy s výkonem jsou nedůležité. Au contraire; problémy s výkonem mohou být ještě nebezpečnější než problémy s kvalitou dat.

Je běžné vyhledávat konkrétní řádky, vkládat nové řádky, aktualizovat nebo mazat hodnoty buněk ve stávajících řádcích a mazat celé řádky. Všechny tyto akce vyžadují hodně filtrování, což na malém datovém souboru není žádný problém. Ale když jsou vaše listy opravdu velké, i jednoduchá operace může trvat minuty. Strávit polovinu svého pracovního dne čekáním, až filtr udělá svou práci, je stěží moudrá volba.

S tím souvisí i problém redundance – ukládání stejných dat vícekrát na disk (např. zákaznická data jsou ukládána znovu a znovu ve více řádcích). To bude mít také dopad na výkon.

Na slušném hardwaru budou listy s tisíci řádky v pořádku. Ale když se dostanete do desítek tisíc řádků, problémy s výkonem mohou zvednout jejich ošklivé hlavy. Netřeba dodávat, že listy se stovkami tisíc nebo dokonce miliony řádků budou mít extrémně špatný výkon.

Na druhou stranu jsou zde databáze od toho, aby řešily problémy s výkonem. Když je vše správně nastaveno, nebude práce s miliony řádků představovat žádné problémy.

Správa historických dat a sestav

Dalším důležitým problémem s listy je sledování změn dat v průběhu času. Pokud data z listů jednoduše smažete, přijdete o ně. Pokud se rozhodnete uložit denní list (pro zachycení všech změn a zachování historických dat), brzy se ocitnete pohřbeni pod tunami listů. Vytváření reportů z takové struktury je opravdu časově náročné a kvalita jakýchkoli reportů z ní generovaných by byla velmi diskutabilní.

Máte takové problémy se svými daty?

V dnešním článku jsme diskutovali o některých nevýhodách používání listů k uspořádání velkého množství dat. Zažili jste někdy některý z těchto problémů? Jste připraveni posunout své podnikání na další úroveň? Pokud je odpověď „ano“, jste na správném místě! Příští týden se dozvíme, jak databáze řeší problémy s ukládáním dat do listů.


  1. Příklady DATEDIFF() – MySQL

  2. Jak odstranit všechny tabulky MySQL z příkazového řádku bez oprávnění k databázi DROP?

  3. Příklady převodu „smalldatetime“ na „datetime“ v SQL Server (T-SQL)

  4. Jaká je ekvivalentní syntaxe PostgreSQL se syntaxí Oracle CONNECT BY ... START WITH?