Permalink Reply by HC on February 15, 2010 at 19:10
For me it's that Big-5 thing :) but when it comes to SAP I suspect integrating with the last Big Things is next. Twitter et all ought to be part of CRM and CRM ought to be in the cloud. I think SAP offered (perhaps in response to salesforce.com) CRM in the cloud and and SAP's 'Gravity' for collaborative Business Process design clearly made an very positive impression in the Wave space - but what's next for SAP and proprietary business software in general? SAP's strength as always is the business know how that comes with the software - but social media also affords new business know how.
Permalink Reply by Mz on February 17, 2010 at 22:46
Gravity does look promising indeed. Here is a really good video illustrating a real world scenario using the social capabilities of g'Wave and the business know how of SAP Gravity:
Hasso Platner talks about in memory column DBs for ERP and not just BI systems.
So what's the difference between a column and a row DB. Simple really if Wikipedia is accurate: column DBs store tables by column first. For example take a student table with the schema Matriculation-number and Name.
A column DB would store mat1, mat2, ..., matN, name1, name2, ..., nameN whereas
a row DB would store mat1, name1, mat2, name2,... matN, nameN.
For analytical applications the column serialization can be faster because related data - the one you want to analyze - is adjacent thus requiring less seek time if the data is read from a harddrive. Seek time, i.e. the time spent moving the read head of the drive, is what most time is spent on.
Other applications such as ERP systems benefit from a row based serialization as one is usually interest in the entire record, not aggregates.
How then can a column DB be of advantage for an ERP system? This is really a question to you because I have not read the answer nor have I seen Hasso's video thanks to my slow connection. The only other thing I could find about column DBs is that compression schemes work better as compression schemes generally perform better if adjacent data is similar (same type?). For an in memory DB there's no seek time so the only benefit I can see is that less memory is required if compression is employed. It must be significantly less for a column DB as otherwise I cannot see the point. Anyone care to enlighten me, please?
HC