Obligatory "ignore this space" : https://sacoronavirus.co.za

The Ultimate Fairytale : A short history of Greece, Rome, Israel, England, France, and Germany.

A relational database is a database of relations: a relation is a tuple.

In theory we apply set multiplication to these relations. In practice, an RDBMS must iterate over every single element of both sets.

We then apply algebra to the elements of the product set. In practice, this is used in conjunction with the available indexes to prevent the iteration aforementioned.

SQL is therefore a very inefficient way of working with data structures. We cannot be entirely sure which indexes will allow our query to be executed optimally {2}, unless we have the source code of the RDBMS; and, if we can comprehend the operation of a database AND are truly rebellious, irresponsible, and corrupt, we may well prefer to write our own indexing routines and file format.

The point of SQL is for users to be able to get their hands on their data: programmers are forced to use SQL, for the sake of them; ever the optimist, I give you a crash course in Structured English Query Language.

There are three parts to the most used type of query: SELECT, FROM, and WHERE: we firstly identify the columns of the tables we are interested in {1}. It may save some frustration if one is in the habit of giving each table an alias.

SELECT a.name,a.email

We then identify the tables and aliases.

SELECT a.name,a.email FROM contact a, contactrel b

Finally, we filter:

SELECT a.name,a.email FROM contact a, contactrel b WHERE a.id=b.contactid and b.user='me' and b.nickname='friendie'

--

{1} I must note here that SQL is a source of frustration to those who are used to nested data structures.

{2} Inner joins in effect are not needed: I can make no comment on efficiency.

Related: Permissions.

Share. -2020 10 09