sql >> Databasteknik >  >> RDS >> Database

Del 3 – Kunder, samtal och möten

Tidigare i den här serien importerade vi SuiteCRMs databasmodell till Vertabelo och visade hur man använder Vertabelos funktioner för att organisera den. I den här artikeln kommer vi att se hur vanliga CRM-data lagras i dess databas. Vi kommer också att kontrollera de antaganden som gjorts i del 2 om relationerna mellan tabeller och deras funktioner. Om det behövs kommer vi att göra ändringar i modellen.

Vad har vi för närvarande?

I del 1 installerade vi SuiteCRM lokalt med hjälp av Bitnami-installationspaketet. Efter framgångsrik inloggning ser huvudskärmen för SuiteCRM ut som nedan:

SuiteCRM-databasen som heter "bitnami_suitecrm" är tillgänglig på plats http://127.0.0.1/phpmyadmin. Kom ihåg att modellen har 201 tabeller.

Vi avslutade del 2 av den här serien med modellen organiserad så här:




Grundläggande krav för ett CRM

Ett CRM ska göra det möjligt för oss att föra register över våra kunder och hålla reda på de kontakter (samtal, möten, etc.) som vi har med dem.

Kunder är centrala i alla CRM-system. Vi behöver lagra deras grundläggande organisationsdata (namn, adress, intäkter, antal anställda) och deras kontaktdata (telefon, mobil, e-post, webbplats och kanske till och med sociala konton). Vi måste också hålla reda på administrativa data, som när och av vem deras register lades till eller uppdaterades i systemet.

När vi tänker på klientrelaterade handlingar tänker vi oftast på samtal och möten. Vi kan också ha några andra åtgärder som inte kräver kontakt med kunden:kontrollera om ett problem är löst, om en betalning har gjorts, sånt där. Vi vill föra ett register över tidigare åtgärder, men vi behöver också förmågan att schemalägga framtida händelser. Dessutom lagrar vi åtgärdens start- och sluttider, vem som infogade och uppdaterade åtgärdsdata, vem som initierade den specifika åtgärden och vem som är ansvarig för den.

Naturligtvis finns det en massa andra saker – som tidigare sålda produkter och tjänster och potentiell nyförsäljning – som vi också skulle kunna lägga till ett CRM. Men i den här artikeln kommer vi att fokusera på hur SuiteCRM lagrar klientdata, samtal och möten.

Hantera klienter

Kundorganisationer kallas konton i SuiteCRM. Här är vad Skapa nytt konto skärmen ser ut så här:

Och här är hur tabellen "konton" i SuiteCRM:s databas ser ut:

Inom accounts tabell, attribut butiksinformation som angetts i Skapa nytt konto skärm:

  • Grundläggande klientdata:name , description , industry , annual revenue "rating , ownership , employees , ticker symbol
  • Kontaktdata:phone_fax , faktureringsadressattribut, leveransadressattribut, phone_office , phone_alternate , website
  • Ändringar av klientdata i CRM:created_by , modified_user_id , assigned_user_id , date_entered , date_modified och deleted .

De flesta av dessa attribut är av typen varchar eftersom CRM måste kunna lagra användarinfogad data av vilken typ som helst.

accounts table är kopplat till många andra tabeller i SuiteCRM-databasen. Alla relationer är satta enligt de antaganden som beskrivs i del 2 av denna serie.

Konton i SuiteCRM är i princip en lista över klienter. De är relaterade till många andra tabeller i systemet:contacts , opportunities , bugs , cases .

I SuiteCRM-speak, kontakter är faktiska personer som vi pratar med för deras organisations räkning (kom ihåg att i CRM-språk kallas dessa organisationer "konton"). Du kan tilldela en ny kontakt till ett konto, enligt nedan:

Individens data lagras i contacts tabell. account_contacts tabell gör det möjligt för oss att relatera många kontakter till ett visst konto.

Möjligheter inuti SuiteCRM är uppskattade försäljningsmöjligheter. De är knutna till försäljningsstadiet. opportunities och account_opportunities tabeller används för att lagra data om flera möjligheter relaterade till ett enda konto.

Som du kanske gissar utifrån deras namn, bugs och accounts_bugs tabeller lagrar data om problem relaterade till vissa konton. SuiteCRM-modulen gör det också möjligt för oss att ange lösningar och spåra bugghistorik. Buggar är relaterade till calls , contact , cases och andra tabeller.

Modulen "case" används för att komma in och spåra servicerelaterade problem. När vi har lagt till ett nytt fall kan vi lägga till buggar relaterade till det fallet.

Samtal

Alla CRM-system lagrar information om samtal till kunder; SuiteCRM är inte annorlunda. För att lägga till ett nytt samtal klickar vi på Aktiviteter --> Samtal och fyll i nödvändiga uppgifter. Vi lägger till ett nytt samtal och kopplar det till ett befintligt konto och en användare i vårt system.

Här är vad samtal avsnittet i databasen ser ut så här:

I calls tabell kan vi se några av samma attribut som i accounts tabell. Attributen created_by , modified_user_id och assigned_user_id hänvisar till den eller de användare som gick in i det här samtalet, ändrade det eller är tilldelat samtalet. parent_type och parent_id par anger vilken tabell som refereras till och det primära nyckelvärdet för den tabellen. De flesta av de andra attributen är självförklarande.

Samma struktur, med en många-till-många-relation, används för att koppla samtal med användare, leads och kontakter.

Efter att ha klickat på Spara knappen kan vi se en ny samtalspost i vår Samtal lista. Nu ska vi kika in i databasen, särskilt i calls och calls_users tabeller.



I calls tabell kan vi se att “parent_type” =Konton och att id:t i parent_id fältet är konto-id. Inuti databasen finns det några tabeller som använder samma attribut för att ansluta till en av en handfull andra tabeller. Medan parent_id kommer att innehålla värdet på primärnyckeln i den refererade tabellen, parent_type anger vilken tabell vi kopplar till.

Naturligtvis i calls_users tabell kommer vi att relatera det anropet till en tilldelad användare.


Möten

"Möten och leads ”-sektionen är gruppen av tabeller som används för att lagra data relaterad till möten och leads. Även om det är uppenbart vad mötesdata kan vara, leads hänvisa till kunders potentiella intresse för våra produkter och tjänster. Senare kommer vi att använda dessa potentiella kunder och relatera dem till möjligheter, samtal och möten.

Vi kommer att märka att vissa allmänna regler för namngivning av fält i meetings tabell och för att koppla samman möten med kontakter, leads och användare tillämpas i detta avsnitt.

Precis som med samtal kan möten även tilldelas användare och relateras till kunder. Vi går in i ett nytt möte genom att klicka på Aktiviteter --> Möten --> Schemalägg möte .

Mötesdatan, när den väl har angetts, lagras i SuiteCRM; vi kan se det i möteslistan. Precis som med samtal kan möten tilldelas konton, kontakter, uppgifter, möjligheter, buggar, ärenden, potentiella kunder, projekt, projektuppgifter och mål.

I databasen, meeting Tabellen innehåller data om det nyligen tillagda mötet. parent_type och parent_id attribut används på samma sätt och i samma syfte som calls data.



meetings_users Tabellen lagrar information om de användare som är tilldelade ett visst möte.



Primära nycklar är slumpmässigt genererade hashvärden. Detta gör att vi kan ha unika värden för varje primärnyckel i hela databasen, inte bara i varje tabell. Detta är särskilt praktiskt när vi använder samma attribut som en främmande nyckel till många olika tabeller. Ett attribut innehåller nyckelvärdet, medan ett annat innehåller namnet på den refererade tabellen. Detta ger mycket mer flexibilitet – mer än vad system som täcker flera verkliga affärssituationer i allmänhet behöver.

I del 4, som avslutar den här serien, kommer vi att titta närmare på resten av SuiteCRM inklusive kampanjer, projekt, möjligheter och dokumentadministration.


  1. PHP &MySQL:mysqli_num_rows() förväntar sig att parameter 1 är mysqli_result, boolean given

  2. Vad betyder =*?

  3. Introduktion till SQL Server Identity

  4. CONNECT BY eller hierarkiska frågor i andra RDBMS än Oracle