Relational databases - there has to be more right?

Question

I really enjoy database design and the whole concept of managing data semantically and all the logic that comes with it.

My knowledge level when it comes to databases is

Answer 1

I think set + relational algebra is a thing that most database users know little about but would do well to learn. When you appreciate the logic involved behind mapping one relation to another you start to see more clearly why things like normalization are good, why NULLs are best avoided if possible, etc. You also start to see the flaws in SQL compared to purer relational query languages, where features impose limitations on the paradigm due to performance reasons, etc.

Answer 2

I believe optimization on existing databases could be interesting to dwelve into. I.e. why you should denormalize tables.

Some basic relation algebra is useful knowledge and closely related to set theory.

Answer 3

Well, to be frankly a database is just a way of storing and accessing data. Pretty much what a file system does too.

A parallel from LDAP is that it is a protocol and by this not a definition of what you can do with it and how it should be implemented, the same could be said about SQL.

So if you want to know more about databases you are actually saying you want to know more about the SQL protocol and/or how to store and fetch data.

You might be interested in searching around for what a 'B-Tree' is and how it is used. Another thing worth looking up is EAV (Entity-Attribute-Value) and why schema's are so important for it.

With that knowledge you could actually role out your own DB and while doing that appreciating what RDBM's already have done for you.

If you want a more practical approach look at the documentation that the open-source PostgreSQL provides, perhaps starting with this.

Answer 4

i would advise narrowing your scope a little. pick an sql server and become expert at it ... for example get mysql, learn the difference between the storage types, the replication types, etc. implement replication in a couple different ways. get a large dataset and try to optimize queries. do some pivots and optimize your indices for that. investigate backup strategies. see how to increase performance in replication and backups when you have a 10gb database that consistently adds 100,000 transactions every day. write software to insert the records and scripts to do replication and backups.

its hard to become an effective dba with no real experience when you try to cover all sql servers. just focus on one ... i'd suggest mysql or mssql, but whatever floats your boat.

-don

Answer 5

It depends on what you want to do with your databases, how does your data look, what are your work flows, how many servers, clients and databases you have to work with ...

So let's pretend that you, like me, have to deal with several databases, not to big (< 100 GB each) and you have many clients with many different needs that make you develop many custom solutions, like producing custom reports or exports. That makes you more of a programmer than a DBA. And what you need is productivity, before performance.

The best solution I came up with, in that situation, is getting rid of SQL, as much as possible. You can achieve that by using some kind of ORM, either home made or existing ones, and thus trading SQL scripting for object programming. Doing that I do in minutes what would takes hours with SQL.

Answer 6

You could start by reading one of the (almost recent) review papers that focuses on the foundations and trends in Databases: The anatomy of databases