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

51–57 of 57 posts

Re: Foundations of Databases (1995)

#51

Post by throwaway823882 »

victor106 wrote: post #33
throwaway823882 wrote: post #9

Earlier quoted context omitted.

Not a book, but I would add to the foreword: "Try not to use them."

Genuinely curious: What are some challenges with using distributed databases?

Distributed [decentralized] databases are basically the most complicated software you can play with that isn't classified/proprietary.

Read through all these Jepsen analyses: https://jepsen.io/analyses

Then consider that those analyses were done under theoretical environments using failures that tests were written for. It doesn't capture all the garden-variety problems that happen when you are running 40 extra-extra-large instances on shitty non-cloud hardware and serving traffic to thousands of high performance apps on a globe-spanning network.

Things that seem stupid or obvious, like just expanding your storage, can be something these databases can't handle. Sometimes there are well-documented problems, like random data corruption, or replication that just stops and never starts again, or an inability to reconfigure a cluster without literally destroying it. So not only do you need to understand consensus algorithms and cutting edge functionality, you also have to become an operational expert on their quirks. Most are practically brand new, making them largely untested in large-scale scenarios, with features that haven't "baked" longer than a month in testing. There's no book to buy, and very few people to get support from.

Sometimes there's no getting around it and they are literally your only option to solve your problem. But it's not worth getting involved in if a non-distributed database can solve your problem.

On the other hand, if you are just a bored engineer and want to see some very big systems explode in dramatic and obscure ways, definitely use a distributed database.

Re: Foundations of Databases (1995)

#52

Post by ggregoire »

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…

Perhaps it’s a French thing but I had hours and hours of data modeling, SQL and database administration during my first 2 years of college, and a class about the foundations of databases during the 4th year, which ended with the project to build a basic relational database in Java.

Re: Foundations of Databases (1995)

#54

Post by goto11 »

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.

In the context of persistent databases, the schema is more important than the algorithms. You can change the algorithms on the fly, but the schema is fundamental.

The strength of the relational model is it is separated from any specific algorithm.

Re: Foundations of Databases (1995)

#55

Post by slver »

goto11 wrote: post #54
slver wrote: post #21

Earlier quoted context omitted.

"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.

In the context of persistent databases, the schema is more important than the algorithms. You can change the algorithms on the fly, but the schema is fundamental. The strength of the relational model is it is separated from any specific algorithm.

There are underlying algorithms and data structures in databases (b-tree, indexing, WAL etc.) and then there are application level data structures and algorithms, like the schema and how you use it in your app.

So if we see data and algorithms disconnected, we're just thinking about different architectural layers.

Re: Foundations of Databases (1995)

#56

Post by eternalban »

From sec. 22.6 (temporal databases):

“Classical logics augmented with a temporal coordinate have been studied extensively, mostly geared toward specification and verification of concurrent programs. Such logics are usually referred to as temporal logics. There is a wealth of mathematical machinery developed around temporal logics; unfortunately, little of it seems to apply directly to databases.

“Although the view of a temporal database as a sequence of instances is conceptually clean, it is extremely inefficient to represent a temporal database in this manner. In practice, this information is summarized in a single database in which data is timestamped to indicate the time of validity. The timestamps can be placed at the tuple level or at the at- tribute level. Typically, timestamps are unions of intervals of the temporal domain. Such representations naturally lead to nested structures, as in the nested relation, semantic, and object-oriented data models.”

I couldn’t find any instances of the words “epoch”, “epochal”, not even “mvcc”. As of 1995, MVCC at least must have been known fairly widely in academia, no? Wikipedia has Starkey’s VAX Rdb/ELN as first commercial MVCC database (and VAXLEN first release in 1981).

So their take on ‘time’ and data seems to be a bit narrow and literal. At the same time, searching the web for temporal logic + epoch also doesn’t turn up anything.

I find this curious. Anyone can shed light on this?

Re: Foundations of Databases (1995)

#57

Post by victor106 »

throwaway823882 wrote: post #51
victor106 wrote: post #33

Earlier quoted context omitted.

Genuinely curious: What are some challenges with using distributed databases?

Distributed [decentralized] databases are basically the most complicated software you can play with that isn't classified/proprietary. Read through all these Jepsen analyses: https://jepsen.io/analyses Then consider that those analyses were done under theoretical environments using failures that tests were written for. It doesn't capture all the garden-variety problems that happen when you are running 40 extra-extra-…

Awesome!!! thanks so much for the info.
Post reply on HN