No Sql
-
I think it is like most powerful tools : used properly, they can be kept quite simple, but the users have to be aware of what they do. Making a tool idiot-proof usually comes with all sort of unnecessary (To the experienced) limitations.
Even for the experienced, those limitations are there for a reason. They catch errors, as well as restricting your design. How many times have you been told by the compiler that you "can't assign this to that" because you forgot the ".Text" property on the end? Or the braces that make it a method call, instead of a delegate reference? And don't forget, there are a lot more inexperienced people designing on the "hope and pray it works" principle than experienced doing it properly. If they get away with it on a small project they use it on a big one. Then you or I have top clean up the mess when they leave...
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
-
Rage wrote:
xml-based database app
:wtf: That sentence gave me the creeps. It must have been an extremely small db, as performance would have been abysmal otherwise. I wouldn't use xml for anything bigger than defining a menu. (I have admittedly used it for exports though :sigh: )
Light moves faster than sound. That is why some people appear bright, until you hear them speak. List of common misconceptions
Jörgen Andersson wrote:
an extremely small db
A few dozen files of a few hundred lines. All loaded in mem right at app start, so no performance issue. It was an easy and cheap solution, believe me. In the embedded world, xml is used for a lot of purposes, not only to define menus.
-
Jörgen Andersson wrote:
an extremely small db
A few dozen files of a few hundred lines. All loaded in mem right at app start, so no performance issue. It was an easy and cheap solution, believe me. In the embedded world, xml is used for a lot of purposes, not only to define menus.
That is a very small "database", so I quite understand you.
Light moves faster than sound. That is why some people appear bright, until you hear them speak. List of common misconceptions
-
Jörgen Andersson wrote:
an extremely small db
A few dozen files of a few hundred lines. All loaded in mem right at app start, so no performance issue. It was an easy and cheap solution, believe me. In the embedded world, xml is used for a lot of purposes, not only to define menus.
We do something similar for our mobile systems. We then wrote a messaging layer to keep the control data up to date when connected, and send / receive transactive data as needed, if a connection is available. I also proposed doing the same thing at a previous company, again for a mobile solution, about 8 years ago now, but in the end they bought something that didn't quite fit our needs instead.
Every man can tell how many goats or sheep he possesses, but not how many friends.
-
As a bemused Relational DB oik, I have noted the emergence of No Sql and not really made sense of it (apart from the obvious - no sql!). This http://martinfowler.com/articles/nosql-intro.pdf[^] has made me better informed. Might be helpful for you too.
I can't work NoSql out, but I'm not sure whether this is just because it is outside the comfort zone or whether it is a solution looking for a problem, or whether just lack of knowledge on my part. The thing seems to be just a glorified way of saying SQL isn't the right storage choice in all situations, which was true before the term was coined.
Sort of a cross between Lawrence of Arabia and Dilbert.[^]
-Or-
A Dead ringer for Kate Winslett[^] -
As a bemused Relational DB oik, I have noted the emergence of No Sql and not really made sense of it (apart from the obvious - no sql!). This http://martinfowler.com/articles/nosql-intro.pdf[^] has made me better informed. Might be helpful for you too.
I've also heard it be referred to as NO SQL, standing for Not Only SQL, hence the "Polyglot Persistence" in the (great) PDF you linked to. We suffer exactly the same issues and have already moved to a NoSQL (ie Polyglot) solution where some data is stored in non-relational (in our case, Lucene) and we're actively working to reduce our reliance on traditional SQL even further. With Microsoft adding Hadoop into SQL 2012 it will be interesting to see what they can do - and also telling that IBM and Oracle are also jumping on the Hadoop band wagon. Maybe if Microsoft had heeded years of customer calls and made SQL horizontally scalable they wouldn't be jumping to stuff in an Apache product. I'm hoping for the best but fearing the worst out of that particular marriage.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
-
I've also heard it be referred to as NO SQL, standing for Not Only SQL, hence the "Polyglot Persistence" in the (great) PDF you linked to. We suffer exactly the same issues and have already moved to a NoSQL (ie Polyglot) solution where some data is stored in non-relational (in our case, Lucene) and we're actively working to reduce our reliance on traditional SQL even further. With Microsoft adding Hadoop into SQL 2012 it will be interesting to see what they can do - and also telling that IBM and Oracle are also jumping on the Hadoop band wagon. Maybe if Microsoft had heeded years of customer calls and made SQL horizontally scalable they wouldn't be jumping to stuff in an Apache product. I'm hoping for the best but fearing the worst out of that particular marriage.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
-
I got to page four (with my eyes propped open, I hope he speaks better than he writes, that is a dull way to introduce a topic) and meth this:
they don’t have a fixed schema, allowing you to store any data in any record
At which point I lost all interest. One of the reasons I like C# is strong typing! Weak typing (presumably with automatic data conversion) is a PITA... What idiots Q&A questioners the inexperienced could do with a completely variable record doesn't bear thinking about.
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
Not all data is always the same. and... It's not loose schemas that kill people, it's bad programmers.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
-
I've also heard it be referred to as NO SQL, standing for Not Only SQL, hence the "Polyglot Persistence" in the (great) PDF you linked to. We suffer exactly the same issues and have already moved to a NoSQL (ie Polyglot) solution where some data is stored in non-relational (in our case, Lucene) and we're actively working to reduce our reliance on traditional SQL even further. With Microsoft adding Hadoop into SQL 2012 it will be interesting to see what they can do - and also telling that IBM and Oracle are also jumping on the Hadoop band wagon. Maybe if Microsoft had heeded years of customer calls and made SQL horizontally scalable they wouldn't be jumping to stuff in an Apache product. I'm hoping for the best but fearing the worst out of that particular marriage.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
Breaking down what gets stored where and why would make an interesting article.
Curvature of the Mind now with 3D
-
Breaking down what gets stored where and why would make an interesting article.
Curvature of the Mind now with 3D
Well, we have Dalek Dave's stuff over in the corner in the paisley box, JSOPs stuff in the triple locked metal case in the basement, Sacha's stuff is hanging on the walls in the foyer...
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
