[slifin]

I don't know, if a system exposed a EAVT database like Datomic where you don't need to normalise tables and you don't have to index manually and the n query problem isn't an issue then I think a non expert could get a lot further with the right UI then someone given a traditional SQL/NoSQL database

It's easy to make things complex and its hard to make things simple but if we can simplify to a data model then we can do declarative programming and make systems more tenable

Thinking in declarative data models is hard if you're not used to doing it, I'd recommend looking at the following libraries in Clojure: Garden, Hiccup, HoneySQL or Drupal's form management, or kind of ReactJS if you stretch your idea is what data is, they can all handle complex but focused tasks

[throwaway_pdp09]

I have to be sceptical about what you say, so understand that comes from lack of knowledge of what you're getting at (but I do know my SQL very well, and I do know declarative programming, of which SQL is an instance)

> EAVT database like Datomic where you don't need to normalise tables

That is a strange comment to me. Normalisation is not about databases but about data management. The value of normalisation doesn't go away just because you're using a different DB, because it's solely about relationships in the data.

> and you don't have to index manually

Woo, don't know what to say to that. Could you provide some pointers to both of these (normalisation and indexing) and I'll do some reading, thanks. I find that very hard to believe (no offence!)

Agreed about the 'hard to make things simple' but

> if we can simplify to a data model then we can do declarative programming

That data model is arguably normalisation. SQL is declarative, and I've seen the results of ignorance applied to that, so I can't buy that just using SQL protects you much (although it does to an extent, I suppose).

Declarativeness makes things easier on the programmer up to a point. When things break, there's not much you can do - and things can break easily in SQL. Writing good SQL, like any program, takes skill.

Also I recall many years ago finding out the hard way that you have to understand prolog's (relatively simple) search strategy to get decent results from it. Just 'declaring' your relationship between input and output didn't work at all well (I don't remember the details but I remember the lesson I learned).