I have been modeling databases for years, to help me generate reports. I'm an on-the-job trained database builder. For the first time the concepts of all the key types are now clear to me. Thanks.
I came only for primary keys and candidate key, but I didn't even realized when I got to the end of the video. The explanation was that amazing. The only part I am a little bit confused is in the compound key.
This is easily going to be my recommendation to my friends and peers who need a recap incase of interviews. So well put together. Most people don't bother going into it with examples and caveats the way you did :)
All of your videos have been super helpful for me. You explain stuff really well and I've had a hard time finding good resources. Would you ever consider making a video on entity relationship diagrams and crow foot notation?
Exceptionally well made content from a naturally gifted instructor. You are helping people like me make it to the end of school in one piece and what you're doing is so valuable. Thank you.
I've worked with computing for 40+ years, much of it with relational data in one form or another. And yet, I've learned some new things from your videos. Thank you for some great content presented in a clear and useful way.
I watched the normal form clarification video by you and now I am here and havent yet finished it... but I am compelled to give you my gratitude for making all things DB so simple. Thank you for that!!! 🙏🙂
Thanks for this great bunch of well put together Information. For intelligent keys I have three rules I follow. - only use it, if there is a real (and known) value in the usage of the ID later - only use it, if you can‘t achieve this value on a better way (e.g. no suitable field in a given database available) - only use inherent and unalterable information in this id (as you mentioned e.g. date of birth.) If you have to use this method with a changable information, try to make it an unalterable property. E.g. if you put the information in a materialnumber if you buy it or manufacture it (m-123, b-739…), think of creating a new dataset when this changes (like a buy and a manufacture version) but keep in mind that you might have to maintain both datasets or think of setting an expired flag on the old one. As you can see this almost always opens a can of worms.
I teach online classes on Cybersecurity and my students often get tripped up by these concepts. I have reviewed a lot of videos and this is by far the best one I have seen. Keep it up!
Your show is full of excellence. It arouses my appreciation for using my favorite application program which is database by using Microsoft Access more and more.💙
This is a great video, I could understand a lot of things that I was seeing and never asked before because I thought they were that way at random. I would like to see more videos on DAX as I find it challenging but I have the conspiracy theory that giving trainings on DAX can infringe copyright somehow. .The complex thing about DAX is how DAX behaves depending on the context of where it's used within Power BI and it's differences from regular Excel Power Pivot DAX models
I like really the simple explanations :) Very well done, this stuff isnt easy. As suggestion for more topics: Design Patterns, and possibly anti patterns? Or if databases are more your thing (I've read some of your replies) Maybe some examples how to manage a lot of data? Various DB systems, or performance tricks and why those work? Or some 'under the hood' explanations as to *why* some things work like they do? Looking forward for more video's :)
Have discovered you today in watching ur tutorials while previously i was struggling from others as i thought to myself that my understanding is so poor nearly i lost interest but now am happy have meet you
amazing breakdown, good examples as well, thanks for putting your time into this. Just curious are you a backend developer? what did get you interested in the database design
Thanks! Actually my background is in business / systems analysis, translating user requirements into solutions. Just purely by chance, I got assigned to a lot of "data" projects and ended up specializing, without ever really intending to, in data modelling and in writing extract/transform/load (ETL) functional specs - especially in the context of data warehouses. There's a side of me that's very logical and precise and also very focused on communicating meanings clearly, all of which maybe accounts for why I find database design to be an interesting pursuit (& also why I like the challenge of finding ways to explain the concepts to others!)
Thank you very much for explaining it in such beautiful way, waiting for your next videos and also can you please make a video on difference between model and schema, I've gone through many websites but unable to grasp the difference.i strongly believe u can decomplexify. Once again thanks for providing amazing content.
can you make a video on different authorization in a database, on the basis of the work the user does. This confuses me when using an orm for my project. New to this and trying to understand more. Great video 👍.
@22:54 - it's probably fair to say that intelligent keys are those most likely to get printed on documents or displayed in emails. They are much easier to read out or reference by humans when making phone calls and so on.
hi, the video was very helpful. Btw, i'm not sure if i understood well the difference between superkeys and composite keys. Superkeys are a type of composite keys that can consist also of one attribute while the other must be 2+?
Thank you for a lovely video. You explained how keys work very well. Can you talk more about best practise? For example you spoke about using natural keys instead of surrogate keys. This is possible, but is it best practise?
Glad you liked the video! There are different schools of thought on this, but in my opinion you should try to use natural keys where possible ... the only problem is that it's very often not possible! So in practice, you'll find yourself using surrogate keys quite a lot of the time. A good example of a situation where you probably can and should use a natural key is in representing currencies (US Dollars, British Pounds, etc.) as these have official ISO Currency Codes (USD, GBP, etc.) Cases like this where there's a consensus standard natural key convention that you'll always be able to rely on are not that common, but when you do come across such a case, you should go for the natural key - that's my view, anyway. There are also times where you yourself are designing the whole system, including the front end, and can invent your own convention regarding codes to be displayed to the user that will represent instances a particular type of thing - like let's say 'O' for 'Open' and 'C' for closed. These are natural keys and it's fine and good to use them.
@@decomplexify Thanks for your feedback. What about in terms of speed. If you used ISO currency codes as a primary key, and then had to share that across multiple tables, would it have an impact on speed (and memory, as it might use more memory), as opposed to a primary key with just int's? What is your take on that?
Having used Relational Dabases since 1976, I have learned some important design rules: (1) never use real data in primary keys. (2) only use globally unique keys, such as UUID, as primary keys. A major problem with most relational database designs is importing and exporting data from one database to another. Using UUIDs solves this problem, and over the years I find is just solves many other problems.
With GUIDs I both agree and disagree, they are only Globally Unique within the scope where they are created, this means that if they are created outside of the database, they should only be created in one "universe", read this in the same machine. Besides that an uniqueidentifier is 16B and an integer is 4B, and if you need more than 4 billion Primary Keys in a table you can go with bigint which is 8B and gives you 1.6*10^19 unique values. This as you are repeating the PK in your FK references, and 16B vs 4B will sum up to really large values. And using GUIDs usially generate a lot of page splits as well, which in the long run equal to bad performance.
