In SQL RDBMS land, people often talk about relations when they actually mean relationships. Sometimes the meaning is clear from the context, but that’s not always the case; so I thought it might be helpful to know which is which and why:

You may be surprised to learn that: relation = set = table. It’s just the mathematical term for it. The letter R in the RDBMS acronym therefore simply means that it’s a type of database that stores its data in tables. Nothing more.

A relationship, on the other hand, are about two or more tables having a field with common data (generally of integer type, if the schema is decently normalized) used for joins. In its simplest form that’s an implicit relationship, and the database doesn’t worry about it one way or another. You can make relationships explicit by defining foreign key constraints.

A join will work without a foreign key constraint, and a foreign key is still a foreign key without a constraint, it’s just that the server in that case wouldn’t care about you deleting a row from one table while a referring row in another table still exists. That’s what foreign key constraints guard against.

Some time ago, business were missing the components needed to run their business – if they wanted to use Open Source software. That is no longer the case, with SugarCRM, Zimbra, and SequoiaERP.
Accounting (general ledger style stuff, and mroe) is possibly the last big challenges; some partically solutions are out there and SequoiaERP is currently working on it too.

So all is well, right? Hmm…

If we look at the proprietary solutions, we see not just groups of applications, but integrated suites from a single vendor. In fact, many of these suites are actually more like platforms for which third parties can develop extensions.

Contrarily, the above is highly functional and great on their own but what I think might be missing is the integration. A business may care about this, because they are unlikely to want to maintain their customer database in both their CRM and their billing system. From their perspective, that just doesn’t make sense!

So, should the abovementioned vendors aim to implement an entire suite? Well, perhaps some will, but that may not be the optimal solution. What I would like to suggest instead is some kind of common ground for the core information that the apps should share (such as basic customer detals).
A simplistic implementation example would be a database with a few tables that contain this information, that the other apps can then “share” and join against from their own additional tables. I do appreciate that an effective solution may be slightly more elaborate and would amount to some kind of API.

So, I guess that this is a kind of challenge to those people and companies working on these applications – will you go and try to resolve this?

I’m just listening to a talk by Rusty Russell (an excellent speaker anyway) about Tridge’s talloc. It extends the traditional malloc() mechanism by making every returned pointer effectively be a memory pool. You can allocate memory that is “attached” to an existing pointer. When a parent pointer is freed, so are its children.

There are additional functions for stealing (re-attaching) a pointer to a different parent, optional destructors, and other useful trickery.

Tridge uses talloc in Samba4, and Rusty has also uses it in various places. Good stuff.

Conferences… Travel… Passports…
The Australian ePassport has been introduced, with very little press attention. The centre page has an RFID chip which contains the same info as the regular passport.
To me, that’s actually big news. And very worrying.

While the “should you be required to identify yourself on the street” debate is still ongoing, this passport already goes a step further. Your identity could be read without asking you.

Sure, there are security features in place. For instance, the info from the machine-readable strip of the passport needs to be scanned to get the trigger sequence for the RFID. And the RFID info is of course encrypted.
But we know that this type of technology can be cracked. And since identity theft is a profitable endeavour, nasties are very likely to spend money on this.
Also, at locations where the passport is being read legally, others could (passively) pick up the transmitted signal. With a sufficiently large sample and the fact that the data format will be fairly fixed, the encryption actually becomes very vulnerable.

In short, I think this is going to be a privacy and identity nightmare.

References:

• The Australian ePassport
• Australia Launches ePassport – Media release by Alexander Downer, Minister for Foreign Affairs, 25 October 2005

About five years ago a Polish Australian, Patryk Zadarnowski, set up a Linux Jewellery store online. As speaker at AUUG conferences, I was lucky enough to receive a little black nickle tux, and a “tux inside” keyring… excellent.

Patryk started it all as a weekend project (together with an artist friend) but he soon found the demand was so high that it turned into a full blown business. It’s had tens of thousands of customers over the years, from around the world.

Now Patryk wants to focus on his post-graduate studies, and so the store is being closed down. For the very last time, the remaining items of stock (and the domain names) are being sold via http://home.exetel.com.au/ljs/

It’s a great pity as it was a great initiative… a few years ago, Patryk and I discussed the possibility of also creating some MySQL-related jewellery. Unfortunately, his artist friend was ill for quite a while and so it was not possible to create new designs…

Anyway, thanks Patryk for your excellent work!