Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Foundations of Databases (1995)

webdam.inria.fr

Post reply on HN
Print view View original

21–30 of 57 posts

Re: Foundations of Databases (1995)

#21

Post by slver »

msluyter wrote: post #11
macando wrote: post #10

It's incredible how little attention is paid to data modeling and querying in the education of people entering the software engineering workforce. Getting your database model right, on the logical and physical level, will make developing and deploying any data-driven app simpler and easier. Getting it wrong? No modern programming language or architectural pattern will save you from the worst kinds of bugs, workaround…

To wit: I made it through a master's in CS without a database class. This reminds me of the famous Rob Pike quote: "Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming." I've often found that if I'm coding something and the code starts looking increasingly gnarly, that rethi…

"Data structures, not algorithms, are central to programming.

Can we unify this to simply "data structures are essential to algorithms". It's really weird to put these in opposition, when algorithm with no data and data without algorithm make no sense.

Data structures are encoded with use cases in mind, those use cases at least at the very low level are their algorithms.

Re: Foundations of Databases (1995)

#23

Post by jenkstom »

We don't need "more theory". The vast majority of computer science theory goes unapplied in solving real-world problems. While I'm sure this is great for postgrad computer science students, it's not very useful for the every day programmers out there.

Re: Foundations of Databases (1995)

#24

Post by marcodiego »

jenkstom wrote: post #23

We don't need "more theory". The vast majority of computer science theory goes unapplied in solving real-world problems. While I'm sure this is great for postgrad computer science students, it's not very useful for the every day programmers out there.

>We don't need "more theory".

>it's not very useful for the every day programmers out there

So, programmer's talent is not being used to their fullest. The ones which can't understand basic theory can be easily condemned to always be mere users of tools while never improving them. They run a greater risk of becoming obsolete or devalued.

Re: Foundations of Databases (1995)

#25

Post by artificial »

jkaptur wrote: post #7
anonymousDan wrote: post #2

Anyone recommend a good book specifically on distributed databases (not more general distributed systems stuff like e.g. klepmann's DDIA)?

In case someone isn't aware, Designing Data-Intensive Applications is a very good introduction to distributed databases, even if it doesn't specialize in them.

I’ll second this. It’s an excellent intro that’s very approachable.

Re: Foundations of Databases (1995)

#26

Post by slyrus »

Was lucky enough to take Serge's class when he was visiting UC Berkeley back in the 90's. And yet I'm still writing SQL :( Curious to know what the state in the art in solving the then-thornier theoretical problems (negation mostly) is.

Re: Foundations of Databases (1995)

#27

Post by Twisol »

slver wrote: post #21
msluyter wrote: post #11

Earlier quoted context omitted.

To wit: I made it through a master's in CS without a database class. This reminds me of the famous Rob Pike quote: "Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming." I've often found that if I'm coding something and the code starts looking increasingly gnarly, that rethi…

"Data structures, not algorithms, are central to programming. Can we unify this to simply "data structures are essential to algorithms". It's really weird to put these in opposition, when algorithm with no data and data without algorithm make no sense. Data structures are encoded with use cases in mind, those use cases at least at the very low level are their algorithms.

I think programming is more than just algorithms. System design and architecture have a real impact on the longevity and maintainability of your system, and I'd argue that data models (not structures per se, the distinction being logical vs. physical) are foundational to a good design. In contrast, algorithms play a much more focused role.

Put differently:

> Data structures are encoded with use cases in mind, those use cases at least at the very low level are their algorithms.

As you've lampshaded, it's the use cases that are most fundamental. The data model should be designed to serve those use cases. The data structures and algorithms reflect the physical reality of the logical data model.

Re: Foundations of Databases (1995)

#28

Post by vishnugupta »

macando wrote: post #10

It's incredible how little attention is paid to data modeling and querying in the education of people entering the software engineering workforce. Getting your database model right, on the logical and physical level, will make developing and deploying any data-driven app simpler and easier. Getting it wrong? No modern programming language or architectural pattern will save you from the worst kinds of bugs, workaround…

Copy pasting my comment[1] from an earlier thread.

A couple of years ago I spent quite some time trying to evaluate the tech stack (and general engineering culture) of merger/acquisition targets of my employer. It was quite a fun exercise, all said and done. I encountered all sorts; from a small team start up who had their tech sorted out more or less to a largish organisation who relied on IBM's ESB which exactly one person in their team knew how it worked!!

I discovered this exact method during the third tech evaluation exercise. When the team began explaining various modules top-down and user-flows etc., I politely interrupted them and asked for DB schema. It was just on a whim because I was bored of typical one way session interrupted by me asking minor questions. Once I had a hang of their schema rest of the session was literally me telling them what their control and user flows were and them validating it.

Since then it's become my magic wand to understand a new company or team. Just go directly to the schema and work backwards.

Conversely, I've begun paying more attention to data modelling. Because once a data model is fixed it's very hard to change and once enough data accumulates the inertia just increases and instead if changing the data model (for the fear of data migration etc.,) the tendency is to beat the use cases to fit the data model. It's not your usual fail-fast-and-iterate thing.

[1] https://news.ycombinator.com/item?id=24137997

Re: Foundations of Databases (1995)

#29

Post by macando »

msluyter wrote: post #11
macando wrote: post #10

It's incredible how little attention is paid to data modeling and querying in the education of people entering the software engineering workforce. Getting your database model right, on the logical and physical level, will make developing and deploying any data-driven app simpler and easier. Getting it wrong? No modern programming language or architectural pattern will save you from the worst kinds of bugs, workaround…

To wit: I made it through a master's in CS without a database class. This reminds me of the famous Rob Pike quote: "Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming." I've often found that if I'm coding something and the code starts looking increasingly gnarly, that rethi…

> "Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming."

I'm saving this quote.

> I've often found that if I'm coding something and the code starts looking increasingly gnarly that rethinking the data structures / data model will clean up the code.

I've faced this over and over again. Writing algorithms is hard when the underlying data is not optimal. It simply invites writing complicated code and workarounds.

Re: Foundations of Databases (1995)

#30

Post by macando »

adamnemecek wrote: post #20
macando wrote: post #10

It's incredible how little attention is paid to data modeling and querying in the education of people entering the software engineering workforce. Getting your database model right, on the logical and physical level, will make developing and deploying any data-driven app simpler and easier. Getting it wrong? No modern programming language or architectural pattern will save you from the worst kinds of bugs, workaround…

> this or any other legendary DB book. What are the other legendary DB books?

https://www.amazon.com/Modeling-Essentials-Third-Graeme-Sims...

My favorite. Not an easy read, it took me weeks to complete it.

https://www.amazon.com/Date-Database-Writings-2000-2006-Chri...

Relatively unknown but great book if you want to read the thoughts of a DB heavyweight Christopher Date who collaborated with Edgar Codd.

https://www.amazon.com/NoSQL-Distilled-Emerging-Polyglot-Per...

The best book to start exploring the land outside the relational world. An easy read, can be completed in two to three days.

Post reply on HN