Choosing a database structure / engine

In my workplace, we just stumbled upon a problem where we need to create a kind of inventory app that stores different types of properties for each object and the ability to dynamically handle properties / columns, i.e. we don't want to have to modify the app every time a new property is for an existing object (let's say Bluetooth hardware now needs to be considered!) or when a new object appears (now we need to consider playgrounds!). Of course, these objects must be readable and editable.

Although we are traditionally SQL-oriented (Oracle, MySQL, MSSQL), I do not mind being able to do it in any other way (say, NoSQL), for which we have never dealt and do not seem to pay attention to, However, we will need to develop ASP .NET MVC.

Any guidance would be much appreciated. :)

+3


source to share


2 answers


Actually, the problem you described is quite solvable through relational dbms, but it will take much longer for your command. I think the document database is the best choice for you. RavenDB is an excellent document database that combines the advantages of both a relational and a document database. It is fully ACID compliant, has a great Linq provider, and is quite fast, especially the newest build.

So my suggestion would be, you don't know exactly until you try it. The only problem I've encountered with ravendb so far has been indexing. The documentation is missing some important notes and I hope Ayende will fix this problem soon, otherwise he'll just go for it.



By the way, you can also try MongoDB. It is not ACID compliant, it also does not have a Linq provider, and the query records are harder than RavenDB, you guessed it, but written in C ++, has atomic I / O and is very fast.

+3


source


If you need to store and process structured data (or maybe sound files, images, etc.) and you are used to Oracle, I would suggest looking into LOB and XMLType. Oracle has built-in support for XML technologies (schema validation, xslt transformation, binary storage, xpath indexes may be areas of interest).



+1


source







All Articles