@normanLinux +1 On Tuesday, November 17, 2015 at 3:28:07 PM UTC+5, normanLinux wrote: > > 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.
