|
|
|
|
|
|
by cwyers
3114 days ago
|
|
|
Leaving aside the politics, boy does the listed example suck. Relational databases are about relations. The trite little employee/department examples we've all seen before work because most people learning about databases immediately can understand a whole bunch of different relations that can occur here. You can think about concrete problems you might want to solve using that data -- figuring out who has to do annual reviews of what employee, doing payroll, etc. You can get a book's worth of mileage just adding things to that simple set of tables. Meanwhile, in this example -- if the ICJ wanted to make a database of war criminals, this isn't close to how they'd do it. Storing the sort of data in the example... using Excel might be overkill, you could do that in the text editor of your choice. This isn't even a toy problem. It's not a simplified version of the real thing for teaching purposes, it's a polemic slapped in the middle of a bunch of boilerplate SQL for no other reason than because the author is bored of writing SQL tutorials and is spicing it up by throwing in a bunch of polemics. There's no connection between the material there and what the user is supposed to be learning. It's distracting. It can be nothing but distracting. If you want to say that using business-oriented examples propagates a certain sort of politics, fine (although nobody is using Oracle for anything else, the license costs rule it out for hobbyist products). But make your examples illuminate what you want to teach, not distract from it. |
|
|
One of the major features of a database is to allow multiple users to simultaneously work on the set of data as a whole without unexpected data loss or conflict*. (Obviously if two workers need to update the same resources and are working with external programs those need to request the correct locks and/or have transaction mechanisms that make sense.)