Database Design Step-By-Step Tutorial for Beginners

[@thedevlife]

You might also be interested in learning the top reasons why self-taught developers fail -> kzbin.info/www/bejne/Y5CygmuebtmmbpIsi=9AZSIkZckVszMfCA

[@captainkeyboard1007]

I watch your show because I relish seeing people use database programs. Microsoft Access is my favorite database brand. It may be intensive you use, but it is full of rich features to make creating and managing database files easier to use like never before.👍

[@thedevlife]

You can have a Users table with attributes to indicate what type of user it is (buyer/admin/seller), then add an AddressId field that will be a foreign key to an Addresses table. That way each user will have an address. It gets a bit trickier if you need to support multiple addresses per user, but that is still doable.

[@lukealadeen7836]

PostreSQL is tge best dbms

[@noorshah96]

Great vid, thanks! Quick note: You were meant to add "Civic" instead of honda in the models last entry 😁

[@nguyenquan4836]

Thanks. Can you do more video like this.

[@prestontym8113]

Location of seller in relation to buyer?

[@mdbelalhossainsanto6523]

upload the next videos, plz!

[@KonradTamas]

When I see the pixelated characters,(like in 1950), then the white background, my mind goes NEEEEEEXT PLEASE or I'll go to sleep !! Thanks for the effort anyways

[@thedevlife]

Thanks for the feedback. I hope you find the tutorials that keep you awake.

[@lukealadeen7836]

Looks fine to me

[@mbalagueraj]

In 1950 tere were not pixels...!

[@ShahariarSm]

Hi

[@thedevlife]

Hello

[@spondoolie6450]

Tell me if I'm wrong because I'm pretty much still a beginner, but instead of making a separate table for any column that can have a handful of different types (ie the Makes table or the Model table) I would rather turn that column into an enum. It seems so much simpler and less redundant than having 10 extra tables in your design .... is there anything wrong with just making the column an enum instead of a separate table?

[@thedevlife]

Excellent question, in some cases having a "enum" value is good enough. In my experience it is ok to reference the code to understand what the "enum" values stand for (if you have 10 or more values and you can't always remember by heart) if you only need to store a simple flag, but this false apart the minute you need to have an additional attribute for the entity you are referencing. For example, let's look at Makes in this video, you easily just keep track of a numeric value to represent the car manufacturer. What happens if you need to also store where the car maker is from? or what year it was founded? You might also need to track (for some use cases) if you still allow if the Maker to be active in your application. Also, one day you might need to filter Makers or car models from a certain country and having a way to do that is to have additional attributes on the Makers table. So... short answer yes I agree, it is a lot easier to keep only an "enum" as long as you are 100% you won't a need to store any additional attributes for a particular entity.