Behöver lite design tips på ett projekt

håller på att utvecka ett litet faktureringssystem som dels ska kunna erbjuda funktionaliteten att skapa ny faktura från scratch och dels (hela poängen med projektet) kunna generera fakuterer från ett bokningssytem (handlar om olika bokade uppdrag/tjänster).

jag har hela tiden tänkt att jag inte vill utvidga databasen för bokningssytemet med massa faktureringstabeller eftersom det är två skilda system varav det ena (bokningssytemet) är i grunden en kommersiell produkt.

om jag då skapar en ny standalone databas för faktureringssystemet med tabeller som invoices, customer, lineitems, items osv är allt fint så länge det bara skulle kunna tänkas användas till att skapa nya fakturer från scratch.

men eftersom jag vill hämta order/uppdragsinformation från den andra databasen för att skapa fakturer (baserat på val av tidsperiod och kund) uppstår det lite problem. jag måste i stort sett duplicera många tabeller som finns i bokningsdatabasen för att kunna lagra information och status om vilka uppdrag som redan har fakturerats och till vilken faktura och vid vilket datum.

är detta en snygg lösning? känns inte som det eftersom jag som sagt i stort sett kommer dubbellagra alla ordrar som faktureras.

tiiiiiiiiiiips?

Om jag förstod dig rätt så har du en tabell med avklarade tjänster som ska debiteras, sedan vill du ha en tabell för fakturorna. Eftersom du inte vill duplikera informationen om vilken debitering som hör till vilken faktura så är det bara att du lägger in en sk. relationstabell för det.

Säg att du har följande tabellstruktur:

Bokningar (eller vad din nuvarande för bokningarna nu heter)
bokningsID kostnad datum köpare

Faktura
fakturaID datum betald

Debiteringar
fakturaID bokningID

Då säger vi att du har utfört två jobb åt en kille med bokningsID 1 och 2, sedan vill du skicka ut en faktura på detta. Då lägger du till fakturan i din tabell faktura med fakturaID 112 och lägger till poster med värden "fakturaID 112, bokningID 1" och "fakturaID 112, bokningID 2" i din tabell Debiteringar.

På så sätt kan du hålla reda på vilken faktura som hör till vilken debitering, och få ut all information du önskar utan att behöva ha dubletter av fält.

Lite opedagogiskt förklarat av mig, men hoppas du förstår principen.

Tillägg: Gällande att du använder olika databaser så vore det optimalt om du använde en databas för alla system men flera olika tabeller, blir onödigt mycket krångel annars.

ja har faktiskt tänkt på den lösningen. problemet som uppstod var att datamodellen inte speglar verkligeheten korrekt.

det du förklarar resulterar i följande förhållande

FAKTUROR
|
en
till
många
|||
DEBITERINGAR
|||
många
till
en
|
BOKNINGAR (andra databasen)

medans i verkligheten kan en bokning endast förekomma i en faktura.

det skulle ställa restrictions på främmandenycklar i relationstabellen..

om jag nu tänker rätt

Restriktionen är alltså att både bokningsId och fakturaId är unika nycklar i relationen, vilket väl är en ganska "naturlig" begränsing om det ska vara en 1-1 relation.

yess där har vi det. visste att de fanns nån naturlig designlösning till mina restriktionskrav som ja glömt bort från databas kurser man hade under skoltiden.

va lite snabb med mitt tidigare svar.

det är ju självklart ingen en-till-en relation jag är ute efter för Bokningar <--> Debiteringar. utan snarare att flera bokningar har en faktura.

alltså det bästa skulle vara om det såg ut så här:

FAKTUROR
|
en
till
många
|||
DEBITERINGAR
|
en
till
många
|||
BOKNINGAR (andra databasen)

detta skulle dock kräva att jag storar referensnyckel till debiteringar i bokningstabellen. men eftersom bokningstabellen är i databasen jag inte vill modifiera så är jag tillbaka på ruta noll. ska jag behöva "kopiera" hela bokningstabellen till databasen jag själv skapat för att skapa den där relationen eller kan man möjligtvis skapa några restriktioner med hjälp av flera unika nycklar i debiteringstabellen för att uppnå samma resultat?

Hmmm.Inte helt 100 på att jag förstår problemställningen, men detta poppar upp i mitt huvud när jag läser den.


Dvs du refererar data i den andra DB, för att göra det så behöver du lagra de id som är relevanta, men inte mer.

Fast det känns som att du redan insett det...

Din tabell FakturaDebitering känns lite malplacerad, skall en debitering kunna finnas med i flera fakturor? Skall en faktura enbart kunna ha en debitering (pga unique)? Själv hade jag nog slängt in FakturaId (foreign) ---> Fakturor direkt i tabellen Debiteringar istället, och skippat FakturaDebitering helt. En debitering har då info om vilket FakturaId den tillhör.

Däremot känns din tabell DebiteringBokning helt rätt, och är förmodligen den bästa lösningen på TS frågeställning. Det borde dock vara BokningId som är unique, inte DebiteringId, eftersom en bokning enligt TS bara kan finnas på en faktura, och därmed bara i en debitering.

Relationer mellan två olika databaser går inte att få till enbart med sql, eller det är i alla fall inte önskvärt att få en sån dependency (hur löser man backup/restore om man sumpat disken? ). Duplicering av hela tabellen är också fel, och hur skulle man göra med de tabeller som den i sin tur dependar på? DebiteringBokning kan istället fungera som en lös koppling till bokningstabellen i den andra databasen, men enbart BokningsId finns representerat här, resten av datat finns i andra db. Man kan till och med ha BokningsId som primärnyckel här, bara man skippar auto_increment.. Med denna lösning är det upp till affärslogiken, förslagsvis din applikation som gräver i bokningssystemet för att generera datat till ovan databas, att hålla reda på relationen. Om du bara håller reda på id, kan en applikation som ser bägge databaserna alltid få tag i det data som behövs och hör ihop.

tack så mycket för att du delar med dig med din syn på det hela.

som du säger så känns det ju som att en förlängning av nuvarande bokningstabell från andra databasen till min databas är den rätta lösningen. med förlängning menar jag då att båda tabellerna har samma primärnyckel, alltså bokningsid ellver vad den nu heter i andra tabellen. förövrigt, vad fan heter det när man har en tabell som förlänger en annan tabell? det är ju rätt vanligt och jag vet att det finns nåt namn för det. (EDIT: kom på att det är ju arv det är frågan om )

min nuvarande modell ser ut så här. andra tips på viktiga delar jag verkar ha glömt? ingen betalningsfunktion ska erbjudas.