![]() But this is also something that you should consider following when you work on your final projects and go out into the real world and start designing databases as well. So I’ll show I’ll, I’ll show this in my upcoming example here. So this is going to be kind of our mantra as we start going through writing our databases. ![]() Most of the time, this just equates to not storing the same data more than once. But this does come with practice and we’ll see some examples of this as we start designing more databases, our other general design principle that we’re going to focus on here is avoiding redundancy. So unnecessary complexity is a kind of a difficult one to avoid because it’s not always apparent that you’re going down a road that is more complex than others. This also can affect our data integrity as a result. But unnecessary complexity, of course, also increase in our database also increases the complexity of our SQL that we have to write in turn complicating our code that we have to write, which makes your your program your programming your SQL code, and the program that uses it more susceptible to bugs and issues down the road. So sometimes we make extra tables when we don’t need extra tables, adding more columns, and we don’t need more columns, and a variety of things in between. Sometimes when we’re working with data and information, it can be a big pitfall to overcomplicate things. ![]() But the first one here is to avoid unnecessary complexity. But these are some of the things that you’ll want to strive for as you’re designing your databases. And we’ll have some more videos that cover these in a little bit more detail. And these are of course, covered at a very high level. Overall, we’re going to talk about a couple primary, a couple primary design principles that we want to follow. Here, we talked about good design that provides data integrity, maintenance of that data, as well as better code as a result for this class. But again, it really depends on the use case. Although sometimes, we do sacrifice some performance to improve the footprint or storage of our database. And typically, better performance on SQL queries. So that usually translates to better performance as far as storage have better efficiency for storage. Of course, less duplicate information means that we’re having to store the same information only once, rather than multiple times. This also helps translate usually to better performance, a well designed database will typically take up less storage, especially with a database that doesn’t store duplicate information. And I’ll show some examples of this here in just a little bit.īut that also helps us write better code as well, allowing us to maintain good quality SQL code that we write as part of our database alongside application code as well that utilizes the results from that database. And a variety of other things in between. poorly designed databases often include multiple copies of the same information, and summon, some copies get updated, some don’t, some get deleted, some don’t. A poorly designed database is going to typically impede our ability to maintain a consistent state of information, and especially maintaining that consistent state across a larger period of time. So this includes anything, any data that gets updated, deleted, all those sorts of things, and also the maintenance of our code. But that also also kind of helps us with maintaining our data as well. But the big point behind data integrity is that we’re trying to avoid unintentional changes of our data, whether that be in transmission, writing, or retrieving our information that we’re actually working with. And then when we retrieve that data, that same data is actually retrieved as well, it didn’t actually change or get corrupted or, or anything like that. But data integrity is one of the big ones, right? So the data that we actually store is, is sent, received and stored in the same way that the users are actually translating it as so you know, if we need to store some number, or string or whatever it may be inside of our database, that same number that is transmitted is stored. And we’ve talked about some of these items, when we talked about the motivation for why we need a database over something like an Excel sheet, for example. So there’s a couple primary things that we’re after as part of a good design. But what makes a database design a good database. And later, we’ll also talk about SQL queries that we can use to actually insert and modify and delete data as well. ![]() We’ve talked a lot about so far how we might make a SQL query to retrieve data. And in this video, we’re going to be starting our discussion on what makes a database a good database. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |