8 ms·
Allegro-cache looks interesting although I haven't tried it: http://franz.com/products/allegrocache/index.lhtml http://franz.com/products/allegrocache/index.lht
by cratuki 19y ago
Allegro-cache looks interesting although I haven't tried it:
http://franz.com/products/allegrocache/index.lhtml http://franz.com/products/allegrocache/index.lhtml
I like the idea of having a powerful datastore within the same process as the application because you don't have the IPC overhead. Although, if you're using prolog you're probably going to be less likely to want to do complex things in memory as you sometimes are with SQL.
Some considerations that come to mind:
1) Relational databases bring a form of 'automatic' documentation to a project in that somebody who hasn't touched it before can expect to make a reasonable start on understanding it by using known tools to look at the schema.
2) You get powerful hot-patching tools with a relational database (sqlplus, psql, or similar) that have the safety of things like foreign key constraints.
3) Major version upgrades. As you're developing you can track db changes by writing change scripts. Then when you do your upgrade you can 'pull the lever'. There's nothing stopping you from doing this with any other structure, it's just something to think about.
- killerstorm 19y agothere's also AllegroGraph product implementing triple store (kinda RDF), that can be accessed via Prolog. i like that kind of data store very much -- it is as convenient as using plain objects, but supports complex queries, and do not have any additional layers like ORM. links: AllegroGraph tutorial: http://www.franz.com/products/allegrograph/doc/lisp/agraph-tutorial.html http://www.franz.com/products/allegrograph/doc/lisp/agraph-tutorial.html my little lispy wrapper to SPARQL: http://abcl-web.sourceforge.net/rdf.html http://abcl-web.sourceforge.net/rdf.html (i like it somewhat more that Prolog used with AllegroGraph :)
- shiro 19y agoPersonal experience from AllegroStore, a predecessor of AllegroCache: - In AllegroCache/AllegroStore, the class definition is the schema definition; so if the newcomer understands class structures he understands the schema. - Hot-patching can be done through plain-old REPL. At least AllegroStore the system took care of key consistency (if it is explicit to the system). - In AllegroStore schema change is handled as class change (of persistent instances). So you can use usual MOP to write update function, which corresponds to the change scripts. The main difficulty, compared to RDBMS, seemed to come from the fact that the stored objects directly formed a graph, not a table. Some people seemed to have a hard time to "think" directly in graphs, and preferred table analogy.