The DeviceMap data-model has come up in passing in previous messages.
Here I would like to argue my view on the matter.
I'm hoping to get the debate on this matter going and also, seeing as
I'm rather exceptionally using HTML in email, that the formatting will
come out OK :-)
The key question is : what is the ideal technology and 'data-model' for
maintaining the DeviceMap device data.
The image below illustrates what I think is the best approach.
DeviceMap Data
It seems obvious to me that 'classic' SQL (A : RDBMS) as opposed to
'newfangled' NoSQL is the best solution in this case :
1. the data model is quite simple, clearly defined and 'relational'
2. the integrity constraints are well understood and easy to define and
implement
3. the data-set is small
4. consistency and durability are essential
5. extra-ordinary speed and massive scalability are not a requirement
6. stability
Additionally, from the point of view of the application used to maintain
(B : Maintenance App) the data :
* any (web-based) app on any stack can access any major RDBMS securely
via a 'vanilla' DAL relying on parametrized stored-procedures
* minimal code required to format and validate data
* additional requirements such as user access, user rights (C : Users)
can be easily accommodated
* transaction, user activity and version (imported/exported data,
generated sets) logs are a given
* ad hoc queries to collect data (number of devices per brand, ...)
and database (data-set versions,...) stats
This model : (A) RDBMS with (B) a 'classic' CRUD application front-end,
accessible by (C) various types of Users could then be used to :
1. Import (validation/normalization) available relevant data sources :
OpenDDR XML, UAProf RDFs,...
2. Maintain and manage the main data-sets, users, data-set import and
export versions and types,...
3. Export or generate data-sets in different formats, technologies and
flavors as required by current and future actual DeviceMap DDR 'clients'
Basically this means that the DeviceMap 'data-model' is 'nothing but' a
set of table-definitions with a collection of (parametrized)
stored-procedures which can be implemented on any sufficiently robust
RDBMS and to which any maintenance application on any stack can be
connected through a classic 'vanilla' data-access-layer.
This leaves the whole thing pretty much platform neutral yet allows
DeviceMap to maintain a consistent data-set and accommodate (export to)
any number of SQL, NoSQL, binary, flat-file or other DeviceMap DDR
'clients'.
I imagine a public 'face' to the maintenance app where any DeviceMap DDR
'subscriber'/user can freely download the data-set of their choice
(technology/platform/flavor, sub-set and even version) for their
DeviceMap DDR client implementation, while an 'authorized personnel
only' side is used to do the actual maintenance and management.
As you may have guessed, my OpenDDR fork uses such a data-model : import
OpenDDR and OMA RDF and export/generate Redis, JSON, SQL and Protobuf
data-sets for the actual OpenDDR code which, as discussed earlier, can
connect to these different data-sources.
The only thing missing, seeing as I'm currently the only user, is the
actual maintenance app (just a collection of tiny individual code-blocks
I now run from a 'command-line').
Looking forward to your comments etc.
Regards,
esjr
