Auteur Topic: Database schema  (gelezen 3431 keer)

0 leden en 1 gast bekijken dit topic.

xvilo

  • Global Moderator
  • Verslaafd DigitalPlace Lid
  • *****
  • Berichten: 2675
  • Karma: -44
    • Bekijk profiel
    • http://www.xvilo.com
Database schema
« Gepost op: december 25, 2015, 03:04:31 pm »
  • [+1]0
  • [-1]0
  • Hallo,

    Ik ben al een tijdje bezig met die invoice maker. Nu wil ik hem toch wat groter oppakken met een user login en daar een history, het aanpassen van gegevens en later nog meer. Maar ik hou het eerst bij facturen. Nu vroeg ik mij af of het onderstaande database schema een beetje goed is. Ik heb in mijn achterhoofd gehouden dat er zo weinig mogelijk dubbele info in moet.



    Zijn er nog opmerkingen? Of dingen die ik anders moet doen?

    //xvilo


    gertmenkel

    • Actief DigitalPlace Lid
    • **
    • Berichten: 1125
    • Karma: 131
      • Bekijk profiel
    Re: Database schema
    « Reactie #1 Gepost op: december 26, 2015, 06:32:21 pm »
  • [+1]0
  • [-1]0
  • Wat is precies de functie van invoice_products? Ik heb nog niet echt de tijd gehad om je code door te kijken helaas.
    Het klinkt namelijk als een lange string met producten, maar misschien heb ik het niet goed begrepen.
    ThePirateBay AFK
    Bekijk de vrije en gratis documentaire!

    xvilo

    • Global Moderator
    • Verslaafd DigitalPlace Lid
    • *****
    • Berichten: 2675
    • Karma: -44
      • Bekijk profiel
      • http://www.xvilo.com
    Re: Database schema
    « Reactie #2 Gepost op: december 26, 2015, 06:36:57 pm »
  • [+1]0
  • [-1]0
  • Ja ik wil daar serialized de producten van de factuur in zetten. Maar Had al gehoord omdaar een aparte Meta tabel aan te maken.

    Maar omdat ik geen vaste producten heb en deze steeds invul bij elke factuur leek me dat extra omslachtig.


    Ik ben een swagboy 6s plus met Tapatalk


    gertmenkel

    • Actief DigitalPlace Lid
    • **
    • Berichten: 1125
    • Karma: 131
      • Bekijk profiel
    Re: Database schema
    « Reactie #3 Gepost op: december 26, 2015, 06:59:09 pm »
  • [+1]0
  • [-1]0
  • Ja ik wil daar serialized de producten van de factuur in zetten. Maar Had al gehoord omdaar een aparte Meta tabel aan te maken.

    Maar omdat ik geen vaste producten heb en deze steeds invul bij elke factuur leek me dat extra omslachtig.


    Ik ben een swagboy 6s plus met Tapatalk
    Ik had inderdaad een aparte database erbij gepakt, scheelt weer deserialisatie. Maar als je niet verwacht dat gebruikers veel wijzigingen eraan aanbrengen, moet het natuurlijk kunnen.

    Een voordeel van een extra tabel zou wel zijn dat je het subtotaal en de uiteindelijke prijs niet hoeft op te slaan (en bugs de twee dus niet inconsistent kunnen maken met de producten die in de database staan). Je kunt dan in de databasequery het subtotaal queryen als de som van de prijs van de producten, en samen met de BTW ook het totaal vervolgens uitrekenen.

    Zo weet je zeker dat de prijs altijd overeenkomt met de producten.
    ThePirateBay AFK
    Bekijk de vrije en gratis documentaire!

    xvilo

    • Global Moderator
    • Verslaafd DigitalPlace Lid
    • *****
    • Berichten: 2675
    • Karma: -44
      • Bekijk profiel
      • http://www.xvilo.com
    Database schema
    « Reactie #4 Gepost op: december 26, 2015, 07:08:29 pm »
  • [+1]0
  • [-1]0
  • De producten blijven vast, want het zijn gewoon facturen van uit geleverde diensten van mijn zijde. Die het zal eens aangemaakt moeten worden en niet weer veranderd. Hoogstens opgevraagd.

    Dan lijkt mij het toch het makkelijkst, voor nu, om het zo te doen. In de toekomst zou ik dat nog kunnen doen met vaste producten...

    Ik ben een swagboy 6s plus en Tapatalk


    gertmenkel

    • Actief DigitalPlace Lid
    • **
    • Berichten: 1125
    • Karma: 131
      • Bekijk profiel
    Re: Database schema
    « Reactie #5 Gepost op: december 26, 2015, 08:37:46 pm »
  • [+1]0
  • [-1]0
  • De producten blijven vast, want het zijn gewoon facturen van uit geleverde diensten van mijn zijde. Die het zal eens aangemaakt moeten worden en niet weer veranderd. Hoogstens opgevraagd.

    Dan lijkt mij het toch het makkelijkst, voor nu, om het zo te doen. In de toekomst zou ik dat nog kunnen doen met vaste producten...

    Ik ben een swagboy 6s plus en Tapatalk
    In dat geval zie ik geen probleem in de database op die manier gebruiken (of misschien misbruiken? :-p)
    ThePirateBay AFK
    Bekijk de vrije en gratis documentaire!

    xvilo

    • Global Moderator
    • Verslaafd DigitalPlace Lid
    • *****
    • Berichten: 2675
    • Karma: -44
      • Bekijk profiel
      • http://www.xvilo.com
    Re: Database schema
    « Reactie #6 Gepost op: december 26, 2015, 10:32:11 pm »
  • [+1]0
  • [-1]0
  • Hahaha mooi, ook de types en lengtes ongeveer goed?


    Ik ben een swagboy 6s plus en Tapatalk


    gertmenkel

    • Actief DigitalPlace Lid
    • **
    • Berichten: 1125
    • Karma: 131
      • Bekijk profiel
    Re: Database schema
    « Reactie #7 Gepost op: december 26, 2015, 11:12:15 pm »
  • [+1]0
  • [-1]0
  • Hahaha mooi, ook de types en lengtes ongeveer goed?


    Ik ben een swagboy 6s plus en Tapatalk
    Ik ben geen expert in databases (werk er weinig mee), maar ik neem aan dat een SQL server een float datatype heeft. Percentages (belasting etc.) kun je misschien beter in een float opslaan dan in een VARCHAR. Zo ook kun je prijzen waarschijnlijk beter in iets als DECIMAL(19,4).

    Ik neem voor de gemiddelde VARCHAR vaak een limiet van 255 voor het e-mailadres, maar daar heb ik niet echt een reden voor (ik denk graag dat dat beter is voor de alignment van de bytes, maar dat zal wel nergens op slaan ;-))

    Een adres en andere lange strings zou ik niet per se een LONGTEXT van maken (een TEXT moet veeeeel meer dan genoeg zijn, misschien zal een VARCHAR met een hoge limiet genoeg zijn).
    TEXT biedt ruimte voor 64KiB tekens, LONGTEXT biedt ruimte voor 4GiB tekens. Je hebt dan wel onbeperkte ruimte, maar die extra ruimte komt op de meeste serverpakketten ten koste van snelheid. Mocht 64KiB toch echt te kort zijn voor een veld, overweeg dan MEDIUMTEXT (16MiB)
    Ook weet ik niet of je in dit geval wel BIGINTs hoeft te gebruiken. Als je uiteindelijk boven de 2147483647 order uitkomt, denk ik dat je toch al wel een ander systeem gemaakt hebt.

    Als je een veilig password algorithme (ik raad bcrypt ten zeerste aan, ontwikkeld tegen brute-forcing op GPU's waar SHA en MD5 steeds meer tegenaan lopen) kun je de lengte van je password hash aanpassen naar je algorithme (bcrypt is 60 bytes en kun je het beste opslaan in BINARY(60))

    Handig artikel dat ik gevonden heb voor datatypes in MySQL: http://korinets.name/mysql-common-data-types.html

    Ook zie ik de tabel invoice_options maar ik zie daar niet echt een verwijzing naar. Ik neem aan dat je een tabel hebt (invoices_invoice_options) met de vorm (INT id, INT invoiceid, INT invoiceOptionId) om de opties aan de invoices te koppelen?

    Zelf vind ik het ook altijd fijner om niet de naam van mijn database in de namen van de columns te zetten (dus een query maken die lijkt op
    SELECT `invoices`.`id`
        FROM `invoices`
        INNER JOIN `users`
            ON `users.custnum` = `invoices`.`recipient`
    in plaats van
    SELECT .`invoice_id`
        FROM `invoice_invoices`
        INNER JOIN `invoice_users`
            ON `invoice_users`.`invoice_recipients` = `invoice_invoices`.`invoice_recipient`
    Dat is persoonlijke voorkeur maar ik vind het zelf duidelijker.

    Daarnaast natuurlijk het standaardverhaal (als je een relatieve database gebruikt zoveel mogelijk foreign keys gebruiken waar relevant, alles wat altijd ingesteld moet zijn als NOT NULL markeren, etc.).
    ThePirateBay AFK
    Bekijk de vrije en gratis documentaire!