It can be quite an advantage for relatively trivial projects. Imagine, however, that you have a project with several programmers working on disparate aspects of your application. team A decides to add new fields for their requirements, Team B adds different fields. Neither is aware of the changes made by the other and each could miss out on potentially useful data as they don't have the full picture - to say nothing of records with one set of extra fields, others with both sets and yet others with neither.
But the biggest counter argument to most NoSQL databases is still the lack of normalisation, which means data getting out of sync. I started my computing career in 1968 and have always heard - and often seen in practice - the two statements: Whenever data is duplicated it can get out of sync. If data *can* get out of sync it *will* get out of sync. Normalisation is not, as some seem to think, about saving disk space. It is about data integrity. Without normalisation you cannot ensure data integrity. How do you ensure, for example, that you have retrieved all of the sales records for a particular product if people have entered the product name differently at different times? Often in more than one incompatible way? Or, for example, have entered the country name in many ways? E.g. the country Ireland can legitimately be called Ireland, Republic of Ireland, Eire and even (for some rather older people) Southern Ireland This is not, of course, a problem with a database such as Orient where you would have a vertex per product (or country) with edges linking to them - perfect normalisation and *much* faster than foreign key links in the collection of indexed files that are laughingly referred to as a 'relational database'. (In an earlier incarnation I worked with the GE/Honeywell IDS database - which bore strong similarities to the new generation of graph databases. This was referred to at the time as a relational database. When I then encountered the more common database types my first reaction was "that's not a database! It's a collection of indexed files!". ) On Tuesday, 17 November 2015 07:00:22 UTC, scott molinari wrote: > > Like I said, schema always has to be controlled in some way. Mongo forces > schema to be in the code, which I think is an advantage, because it puts > the storage of state and all its complexities in the background. > > Scott > -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
