4 ms·
Trivial example of what people need to know in enterprises: “Tell me whether pet rocks are selling better than Barbie dolls in the south?” What people really
by edw519 16y ago
Trivial example of what people need to know in enterprises:
“Tell me whether pet rocks are selling better than Barbie dolls in the south?”
What people really need to know:
I already know from existing reporting that 984 orders (18% of our backlog) are already past due. For those 984 orders:
- How many are for one item and how many are for multiples?
- Do we own what we owe those customers?
- If we do own it, is it in the proper warehouse?
- If it is in the proper warehouse, can we find it?
- If we can find it, is it undamaged and certified?
- If it's shippable, do we have enough labor to ship it?
- If it isn't certified, how soon can QA certify it?
- If it isn't in the right warehouse, can we move it?
- If we don't own any, where can we get some?
- Which vendors have it on the shelf?
- Which vendors do we have blanket purchase orders with?
- Which vendors do we have contracts with?
- Which orders can be split to satisfy a partial?
- Which orders are for customers already on credit hold?
- Which customers are threatening not to renew with us?
and (ironically) the most asked question of all:
- Which orders must be shipped to hit our quarterly numbers?
I can go on and on; this is just off the top of my head. We like to pick on enterprises, but this is the shit that really happens all the time. So whenever you get gas in your car, bread on your table, new shoes at the mall, steamed milk in your latte, etc., etc., etc., rest assured that someone, somewhere has asked these questions. Questions that were probably answered using some form of RDBMS, SQL, ACID technology (with really good application software on top of it).
- thibaut_barrere 16y agoSQL is actually quite often a bad way to try to answer those questions, too! See http://philip.greenspun.com/wtr/data-warehousing.html http://philip.greenspun.com/wtr/data-warehousing.html for an entertaining explanation. I believe MongoDB in particular can be a fairly good solution to build datawarehouses (I'm starting to use it for reporting systems). One great point about MongoDB is that it makes the ETL process a lot easier (you don't have to prepare tables with the right schema and it supports large amounts of data). I wouldn't be surprised to see some NoSQL solutions get wider adoption in the enterprise, either alone or with tools that build upon them. As for the article: it's pure linkbait in my opinion!
- jaxn 16y agoI used to be a Business Intelligence consultant for enterprises. We built reports, data warehouses, dashboards, etc. From my experience, the article is spot on, not linkbait. Maybe MongoDB is better once you have a well defined query that you need, but I think the point of the parent comment is that those examples of queries are ad-hoc. NoSQL is not as good as SQL when it comes to report specs that are constantly in a state of flux. I need my data available to answer questions. When building a product you have a well defined set of operations based on the features of your product. When the requirements shift on a regular basis, NoSQL is too limiting. When the article talks about a low level query language being too limiting, they are talking about missing things like CONNECT BY PRIOR or SUM(CASE IF col IN ('a','b','c') THEN 1 ELSE 0). These are the same kinds of things that are difficult to do with an ORM.
- aloneinkyoto 16y agoBoth of those queries are very easy to perform in MongoDB. For examples of how to easily model and query trees (CONNECT BY PRIOR in SQL) see: http://www.mongodb.org/display/DOCS/Trees+in+MongoDB http://www.mongodb.org/display/DOCS/Trees+in+MongoDB SUM(CASE IF col IN ('a','b','c') THEN 1 ELSE 0) can be implemented as a group or mapreduce query. I would say that you have a lot more power and flexibility in MongoDB compared to an average SQL database when it comes to ad-hoc querying.
- jaxn 16y agoI am not a MongoDB expert by any stretch, so please correct me where I am wrong. The way I read your link it sounds like I need to store the data in a particular way in order to run a parent/child query. That is great if I know that I need that query at design time. What happens if I have tens of millions of records and need to run that report on an ad-hoc basis? Where the relationship may or may not be important? What if I want to sum the "cost of goods sold" one day and the "items per transaction" the next? Does that not require someone to write code more complex than SQL? Because on Oracle a business analyst can open up Toad and run that query. If I am wrong then it very well may be that the problem is one of the enterprise not being aware.
- ratsbane 16y agoHaving spent an unpleasantly large part of my life enmeshed in it, I strongly disagree with the last statement "with really good application software on top of it." Otherwise, spot-on.