141–147 of 147 posts
Earlier quoted context omitted.
Which is not turing complete. You need database specific extensions to get that. Edit: Also, not all databases follow the standard very closely
Aren't vendors finally starting to abandon their proprietary crap in favor of SQL/PSM?
http://en.wikipedia.org/wiki/SQL#Procedural_extensions
It looks like a lot of vendors still only support propriatary extensions.
Earlier quoted context omitted.
Which is not turing complete. You need database specific extensions to get that. Edit: Also, not all databases follow the standard very closely
I'm sorry but I don't even know what you are talking about. Who cares if ANSI SQL is Turing complete? It stores data just fine and is not vendor specific.
ANSI SQL is not vendor specific but it is just a standard not an implementation. As a result you have to rely on vendors to implement the language. Many vendors deviate from the standard. This means that you cannot just write ANSI SQL and expect it to work on all databases.
Earlier quoted context omitted.
These are all good points but the core of Fowler's article is that the persistence is against the application's object structures directly, with no translation to relational concepts needed (note I am the author of a very popular object-relational library, so I'm not in any way opposed to object-relational mapping...it's just interesting to see this approach that requires none). That it's stored in memory and is reco…
Initially he makes it sound like there is no translation into a different model but at the end of the article he takes it all back and for good reason: Also it's important to keep a good decoupling between the events and the model structure itself. It may be tempting to come up with some automatic mapping system that retrospects on the event data and the model, but this couples the events and model together which mak…
With such an application I'd probably still be writing the events themselves to a relational database for archiving and potentially sending out report-oriented data as well. I'm not sure how all of that would work out re: ultimately the whole app needs to be stored in an RDBMS anyway for various reasons but it seems interesting to try.
After reading the article and all the comments here, and from my own experience, I just don't think it's possible to not have a DB. At best, you write your own basic DB, because you don't need anything fancy. For example, you write S-expressions to files like Hacker News does. This is clever, because the file system has some of the features of a database system, and files and S-expressions are abstractions that alrea…
Was there something specific it the data model that made the versioning hard to write? Or was it that, for this to work across the board, the entire model had to be versioned? It sounds that SQL itself wasn't the problem. Were you looking for versioning alternatives in SQL that weren't up to par?
For example, it's possible that logging all data model changes to a text file would have given us the persistence we were looking for without bridging all our data to SQL. Cutting out SQL from our production set-up would have been an inherent win -- one less process to manage, one less black-box source of complexity, etc.
Earlier quoted context omitted.
You don't even need the capacitors or battery backup if your memory is sufficiently distributed.
Hmm, not so sure about that - power outages can affect several city blocks and then you're introducing latency?
Earlier quoted context omitted.
> In my view, direct access to data decoupled from application code is a bug, not a feature. With multiple code bases touching the same data, schema improvements become nearly impossible. It's unclear that multiple applications with direct access to said data make schema improvements any easier. The obvious solution, copying the data for applications that are using the new schema, pretty much guarantees that one or m…
Very well put. It is not access type (direct vs indirect) that make schema improvements hard, but access preservation: availability. And indeed copying the data often leads to one or more of the copies being wrong, unless special measures are taken in that direction. > How do you guarantee that all of the apps that touch that data use the current version of said code? An approach that may be worth considering is to n…
An e-mail address in your profile would have made that possible. (Chronicdb looks interesting and complements something that I've been thinking about. I suspect that you've implemented many of the relevant mechanisms.)