Data Modeling Quotes

Bad programmers worry about the code. Good programmers worry about data structures and their relationships.

I'd say that my profession ends where architectural thinking ends - architectural thinking in terms of thinking about programs and organizational structure. These abstractions play a role in many other disciplines, and those disciplines are now defining their 'architectures' as well.

Rob Engle and I are concerned with extracting useful implications from economic data, and so the properties of the data are of particular importance.

The problem with data is that it says a lot, but it also says nothing. 'Big data' is terrific, but it's usually thin. To understand why something is happening, we have to engage in both forensics and guess work.

I remember my friend Johnny von Neumann used to say, 'with four parameters I can fit an elephant and with five I can make him wiggle his trunk.'

With four parameters I can fit an elephant, and with five I can make him wiggle his trunk.

We think of enterprise architecture as the process we use for fully describing and mapping business functionality and business requirements and relating them to information systems requirements.

The key to artificial intelligence has always been the representation.

Web pages are designed for people. For the Semantic Web, we need to look at existing databases.

In a single sentence the moral is: admit that complexity always increases, first from the model you fit to the data, thence to the model you use to think about and plan about the experiment and its analysis, and thence to the true situation.

The biggest challenge in big data today is asking the right questions of data. There are so many questions to ask that you don't have the time to ask them all, so it doesn't even make sense to think about where to start your analysis.

You need to use data science and machine learning to get the ground truth of what's happening inside of a company.

Like Netflix, Looker started as nothing more than an idea. Lloyd Tabb and Ben Porterfield were two brilliant engineers who had figured out a better way for businesses to see and analyze their data, and they asked me to join them to help out with the ABCs - that's short for Anything But Coding.

If you have to forecast, forecast often.

For a long time, nobody had figured out Information Architecture, so we all just made stuff up.

On the way from Chicago, I spent the summer of 1947 in Ottawa, helping to build the first of a series of econometric models for the Canadian government.

We use nearly 5 thousand different data points about you to craft and target a message. The data points are not just a representative model of you. The data points are about you, specifically.

The only useful function of a statistician is to make predictions, and thus to provide a basis for action.

We have the best mathematical economic models in the world, and just because our models have been wrong for 14 straight quarters does not mean that they will be wrong in the 15th quarter.

I am frequently astonished that it so often results in correct predictions of experimental results.

Well, we'll look at the hundred thousand type A personalities, and then we'll have a look at the corresponding data points that we have on those hundred thousand people. We'll have a look at what attributes they have in common and then we'll build a model based on that.

Then: I google "time-series visualization" and start work on a new version of my model, thinking that maybe I can impress her with a prototype. I am really into the kind of girl you can impress with a prototype.

My particular interest for the past couple of years has been to really think deeply about the big impendence mismatch we have between programming languages, C# in particular, and the database world, like SQL or, for that matter, the XML world, like XQuery and those languages that exist.

I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships.

Forecasting