My reactions, offhand: On 11/22/06, Eric Hestenes <erichestenes at vikiwi.com> wrote: > Q1: Is there any reaction to the idea of using a triple store? > > Q2: Is use of a triple-store "over engineering" the solution, or is it > called for? If any design problem calls for such a thing, this almost surely does. I have a couple major concerns: * how is the performance of the existing triple-store frameworks? sql is likely to be harder to work with, but is known to scale pretty well, and all existing serious implementations are very seriously optimized for speed. I have no idea of the state of the triple-store frameworks in this respect, particularly in comparison with the complex sql queries that you correctly note would often be necessary for comparable operations in an sql framework. * how would this interact with data stored outside the triple framework? Are there performance considerations (e.g., each page load hitting both the triple store and an sql db); or complexity considerations (e.g., losing the development advantages of a triple store if each developer must learn/use both a triple store and a db framework?) My sense is that inevitably at least other data will end up in a good old-fashioned SQL db (because of the performance, flexibility, and ubiquity of SQL), so you should consider the interactions between stores when considering whether to use an additional store. > Q3: If a triple store is over-kill, are there suggestions on the approach > for creating a persistent metadata model (as data structures) so that it > supports the application at runtime and also analytics about the metadata > model after the system is deployed. If the triple store isn't the way to go? 'hire an sql guru' :) But I think you're probably right that if performance, etc., are reasonable, and there aren't any hidden penalties when the triple store is used in combination with the inevitable sql DB, then the triple store seems like the right solution for this problem space. HTH- Luis
