Live data from Hacker News

A Relational Spreadsheet

kevinlynagh.com

41–50 of 77 posts

Re: A Relational Spreadsheet

#41

Earlier quoted context omitted.

excel.new has a "weird" TLD, no mention of Microsoft in the domain and asks me to auth with my Microsoft account before I can even see the site. If I came across this in the wild, I'd for sure think this is some phishing or generally bad website.

Agreed. That’s bad even for Microsoft. What is wrong with excel.office.com with a version toggle?

excel.new is a shortcut to creating a new spreadsheet, not a brand new version of Excel

Re: A Relational Spreadsheet

#42

Earlier quoted context omitted.

Microsoft Access is this. It was quite popular in its heyday, but as time wore on, it turned out that people eventually either want scalable, real, full-blown databases, or infinitely flexible spreadsheets. Anything built with a product in that grey area in between will eventually want to go one way or the other.

Is SQLite a "scalable, real, full-blown database"? That's the scale that Access is going for. (Though it also totally works as a pure frontend to a "real" database connection.)

SQLite can be used to help build a "scalable, real, full-blown database" application. JET, the SQLite-like engine used by Access, could theoretically be used in the same way.

But the topic here is about GUIs which serve the middle-ground between the "scalable, real, full-blown database" applications and the lowly spreadsheet. The SQLite project offers nothing that is comparable to Access.

Re: A Relational Spreadsheet

#43
post #2

I want the same, I want it so much that I have been working on gasp gui code to do such, an activity I have found I am profoundly bad at. But the theory is, I love the relational database, they are a sort of rigorous superset of the spreadsheet, and I have replaced all my spreadsheets with database tables, however while it is very hard to beat sql for rich comprehensive data transforms and analysis, ad-hoc data entry…

Microsoft Access is this. It was quite popular in its heyday, but as time wore on, it turned out that people eventually either want scalable, real, full-blown databases, or infinitely flexible spreadsheets. Anything built with a product in that grey area in between will eventually want to go one way or the other.

Access had the capability to use a full-blown SQL Server back end, while retaining 90% of the flexibility on the front end. For example, adding a column in Access would add a column in the database table!

We can have our cake and eat it too.

The mistake with Access was that instead of keeping a deathgrip on its legacy file-based roots, it ought to have "grown up" and become a web-native HTML5 app that uses SQL Server back-ends as the only option.

I still think there's a huge market for something like this.

Re: A Relational Spreadsheet

#44
post #35

[Laughs in pandas] I don't want to be dismissive, this is nice work and it's clean and lightweight. But it might be good to look at existing solutions in this area - pandas was developed within the financial industry to solve exactly this sort of issue. If you need more topological flexibility there is xarray, and if you need spreadsheet type immediacy it's worth looking into Mito. Rustaceans should look into pola.rs…

[Sobs in hours spent in pandas documentation] Or, just use a relational database. Alternatively, airtable and similar are basically relational databases that have some really neat features that let you create relationships by just copying/pasting data, or importing CSVs. They're limited in a lot of ways, but it solves a certain set of problems that can't be solved with code or excel.

I went through that as well; Wes McKinney is super-smart, but not the best teacher, and unfortunately his style of example has become a norm ion Stack Overflow etc.

  import pandas as pd

  df = pd.whaaargarrrrbllllll[(['what']['the']['fuck'), is.this['shit'], I, mean, seriously]

  (outputs)

  df[.astype('int64').fillna('spork')
  df.groupby[['uppers']['downers']['all arounders']].join(inner, child, trauma, (yes && no))

  df['confused'].very(simple['example']) # the thing being explained 
I'm exaggerating, but not by much. Most examples in documentation or McKinney's tutorial work is presented as a complete small program in a REPL, and while that does make it easy to follow along by imitation, learning pandas feels like a painfully fragmented process at first. Also, tehre's a widespread assumption among pandas experts that people coming to pandas are already familiar with SQL, even more than Python in fact. I'm sure this reflects the initial user base and to bfair it's probably a true assumption for a lot of folk. But if you came from a more CS or scientific context rather than a database one, it's anotehr avoidable layer of confusion.

I can't recommend a book unfortunately - I just worked with McKinney's own materials and suffered for a while until things started to click. Once I realized what I found frustrating about the tutorial materials I began to realize that I could read it more selectively - and also that the code base is in constant flux. There are often 2 or 3 different ways to do the same thing, with different approaches being deprecated or promoted over time.

Re: A Relational Spreadsheet

#45
post #35

[Laughs in pandas] I don't want to be dismissive, this is nice work and it's clean and lightweight. But it might be good to look at existing solutions in this area - pandas was developed within the financial industry to solve exactly this sort of issue. If you need more topological flexibility there is xarray, and if you need spreadsheet type immediacy it's worth looking into Mito. Rustaceans should look into pola.rs…

[Sobs in hours spent in pandas documentation] Or, just use a relational database. Alternatively, airtable and similar are basically relational databases that have some really neat features that let you create relationships by just copying/pasting data, or importing CSVs. They're limited in a lot of ways, but it solves a certain set of problems that can't be solved with code or excel.

I was wondering the same, why not SQL?

> This leads to a lot of logical conditions, since to prevent double-counting each aggregate tuple’s conditions must assert both that the matching tuples matched and that the non-matching tuples didn’t.

I understand and know to handle edge cases with SQL, I'd have to learn that all over again with a custom language and its own unique quirks. If I was putting such an investment, I'd want it to be better established.

Unless of course it's to scratch an itch and this is a perfect way to start out and share. Nice work and good luck.

Re: A Relational Spreadsheet

#46
post #35

Earlier quoted context omitted.

[Sobs in hours spent in pandas documentation] Or, just use a relational database. Alternatively, airtable and similar are basically relational databases that have some really neat features that let you create relationships by just copying/pasting data, or importing CSVs. They're limited in a lot of ways, but it solves a certain set of problems that can't be solved with code or excel.

I went through that as well; Wes McKinney is super-smart, but not the best teacher, and unfortunately his style of example has become a norm ion Stack Overflow etc. import pandas as pd df = pd.whaaargarrrrbllllll[(['what']['the']['fuck'), is.this['shit'], I, mean, seriously] (outputs) df[.astype('int64').fillna('spork') df.groupby[['uppers']['downers']['all arounders']].join(inner, child, trauma, (yes && no)) df['con…

[deleted]

Re: A Relational Spreadsheet

#47
“ In trying to tidy up my finances I had to rebalance my portfolio, but even though I had all of my trades loaded into a spreadsheet, I found it difficult to aggregate them by ticker / account / category and calculate the actionable bit — the stocks and quantities I needed to buy/sell to meet a desired allocation.”

Is this not what a pivot table does?

Re: A Relational Spreadsheet

#48

“ In trying to tidy up my finances I had to rebalance my portfolio, but even though I had all of my trades loaded into a spreadsheet, I found it difficult to aggregate them by ticker / account / category and calculate the actionable bit — the stocks and quantities I needed to buy/sell to meet a desired allocation.” Is this not what a pivot table does?

[deleted]

Re: A Relational Spreadsheet

#49

[Laughs in pandas] I don't want to be dismissive, this is nice work and it's clean and lightweight. But it might be good to look at existing solutions in this area - pandas was developed within the financial industry to solve exactly this sort of issue. If you need more topological flexibility there is xarray, and if you need spreadsheet type immediacy it's worth looking into Mito. Rustaceans should look into pola.rs…

I see your pandas (even the arrow based pandas 2.0) and raise you polars. ;)

Re: A Relational Spreadsheet

#50

[Laughs in pandas] I don't want to be dismissive, this is nice work and it's clean and lightweight. But it might be good to look at existing solutions in this area - pandas was developed within the financial industry to solve exactly this sort of issue. If you need more topological flexibility there is xarray, and if you need spreadsheet type immediacy it's worth looking into Mito. Rustaceans should look into pola.rs…

I work in finance and I hate pandas! Also worth pointing out that almost all big banks have their own functional languages baked into excel that allow not only relational operations and extend excel functions but also tapping into their inhouse analytics libraries written in C++.

The polars syntax is hella nice. It’s also much faster to boot.
Post reply on HN