pluggable data store architectures

Question

I have a pluggable system management tool. The architecture of this kind of thing is well understood (interfaces, publish/ subscribe, ....). How about the data store though. What do people do?

I need plugins to be able to add new entities, extend existing entities, establish new relationships, etc.

My thoughts (SQL), not necessarily well thought out

• each plugin simply extends the schema when they are installed. In the old days changing the schema was a big no-no; now databases are very relaxed about this

• plugins have their own tables. If 2 of them have an entity (say) person, then there are 2 tables p1_person and p2_person

• plugins have their own database

• invent some sort of flexible scheme where the tables are softly typed. Maybe many attributes packed into a single attribute. The ultimate is to have one big table called data, with key of table name & column name and a single data value.

Not SQL

• object DB. I have no experience with these. Anybody care to pass on experience. db4o for example. Can I change the 'schema' of objects as the app evolves

NO-SQL

• this is 'where its at' at the moment. Most of these seem to be aimed slightly differently than my needs. Anybody want to pass on experience with these

Apologies for the open ended question

Answer 1

My suggestion is go read about the entity framework

a lot of the situations you are describing can be solved (very elegantly) using table inheritance.

Your idea of one big table called data makes the hamsters in my computer cry ;)

The general trend is away from weakly typed schemas because they cannot be debugged at compile time. What you get from something like entity framework is a strongly typed extenislbe schema that you can code against using linq.

Object databases: like you i havent played with them massivley - however the time when i was considering them was a time when there was no good ORM for .net and writing ado.net code was slowly killing me.

as for NO-SQL these are databases that meet a performance need. SQL performs badly in situations here there are lots of small writes occuring. I say badly tounge in cheek - it performs very well but when you scale to millions of concurrent users everything changes. My understanding of no sql is that it is a non rationalised format designed for lots of small fast writes and reads. The scale of sites that use these is usually very large.

OK - in response

I am currently lucky enough to be on a green field project so i am using EF to generate my schema. On non greenfield projects I use sql scripts to update my table structures. As for implementing table inheritance in sql its very easy once you know the concept, its essentially a one to many relationship with a constraint that it will only ever be 0-1.

I wouldn't write .net code that updates the database structure ... that sounds like a disaster waiting to happen to me.

Beginning to think i have misunderstood what you are looking for. I find databases to be second nature as I have spent so long with them.

I haven't found a replacement for being meticulous about script management.