Re: Big Data analytics with Hadoop
Date: Tue, 17 Jul 2012 10:11:03 -0700 (PDT)
Message-ID: <48345425-47e7-49ef-a03a-f8ab1ece02da_at_km7g2000pbc.googlegroups.com>
On Jul 17, 5:02 am, Mladen Gogala <gogala.mla..._at_gmail.com> wrote:
> On Mon, 16 Jul 2012 08:59:26 -0700, joel garry wrote:
> > Well, I think one thing they are trying to do is data mining, separating
> > the very small wheat from the very large chaff. Far be it for me to get
> > in their way. It's just so far away from what I do it's hard to
> > understand why anyone would care. But it's easy to understand:
> > anything that is near the bottom of an s-curve in growth has a lot of
> > exciting opportunities. Dumbass marketers and other leaches try to sell
> > to us inappropriately. Well-proven technologies get decremented too
> > fast. That's the thing we must fight.
>
> We must fight? I'm a lover, not a fighter. Fortunately, the model that
> was formally invented by Ted Codd and Chris Date is still the most
> appropriate for business purposes. It's based on accounting. Database
It's based on math. Accounting is based on avoiding manual errors and catching malicious employees.
> tables map directly into accounting tables. Object tables do not. XML
> doesn't do that. Tables, look-up tables and indexes correspond perfectly
> with the business objects known to any CPA.
This is only true for systems that automate manual operations with no analysis. I could go on and on about how accountants don't get relational design at all, and that doesn't make them bad accountants.
> Techies trying to invent "the next big thing" may have technologically
> sound ideas but are out of touch with the business. The infamous ACID
> rules, whose very relaxed application has made MongoDB so fast, can be
> described as follows:
>
> 1) If my check is not covered, the transaction will produce
> no effects (Atomicity)
> 2) When I write a check, neither my account will be debited, nor the
> check receiver's account will be credited, before the transaction is
> complete. (Consistency)
> 3) The books will only be updated when the transaction is complete. Any
> transaction can only see the state of the books as it was when it
> has begun. (Isolation)
> 3) The books will be complete and accurate. No transaction data
> will be lost. (Durability).
Your first number 3 (lol) and some of the others don't account for cost accounting, cash flow analysis, time value of money, the arbitrary nature of general ledger accounts and plenty of other fairly normal accounting procedures. A big chunk of accounting is to deal with the second number 3, finding the damn mistakes, including rounding errors.
>
> Those infamous rules are, as a matter of fact, basic accounting rules.
> The techie innovations must satisfy one crucial request, in addition to
> being sexy to programmers: they must map well into the existing business
> model. NoSQL, with its speed, coming from relaxing things like locking
> and rollback, is usually used for data warehousing, where it has its
> place. Using it to conduct business transactions, in an OLTP system,
> would be suicidal. That's the secret behind RDBMS longevity and survival.
> It's the same as B-52: contrived and designed in 1946, there is still
> nothing better. There is nothing to fight. A CIO or two may go for a fad,
> but only on test machine and with a test implementation. Nobody will risk
> a business. Oracle will still dominate the server rooms and the only
> force that might push it out of there is DB2, if IBM gets serious about
> selling DB2 on Linux.
Back when Joe Celko was doing his sql puzzles, I thought that was a pretty good empirical proof at how badly sql maps to business problems. And now, look at all the modern features of Oracle that have been added because businesses demand them. Are they relational? Or are some of them not relational, and some pushing some pretty limber feats of contortion into the the sql engine?
Business people bet all the time on all sorts of things, technological and otherwise. The fails are in the newspaper every day. I think most of us can come up with many tech examples, as fails are interesting. Yet we are frustrated because we know how to do it right.
jg
-- _at_home.com is bogus. Fail Of The Day: http://www.theregister.co.uk/2012/07/16/nokia_lumia_sales_guesstimates/Received on Tue Jul 17 2012 - 12:11:03 CDT