Upitor

Feels a little weird, given that there is an easy closed formula for the solutions.

Where do you see the upcoming support for multidim data? Link?

In my experience, NWP data is big. Like, really big! Data over HTTP calls seems to limit the use case a bit; have you considered making it possible to mount storage directly (fsspec), and use fx the zarr format? In this way, querying with xarray would be much more flexible

They are still not syncing directly to the AC grid. They are not going 50 rounds per second

I see. I should have read the article more carefully :-)

Also, consider a ‘sales’ table with multiple references to a ‘calendar’ table: [shipped_date], [order_date], [received_date]

In my opinion this proposal seems only to consider simple cases, but there are many not-so-simple relationsship types:

Consider a ‘sales’ table which includes columns [time] and [sold_by_employee_id], and a periodized ‘employee’ table which includes columns [employee_id], [valid_from] and [valid_to] columns. There is a perfectly valid relationsship between the two tables, but you cant join them using only equal-statements (you need a between-statement as well)

The author makes a case against using “valid_from”/“valid_to” columns on your table. But in my experience, that is the only viable solution. Fx joining an employee-table and a department-table needs to take into account when an employee was in which department. How would do that with some git-like version control for data? That might be useful for some machine learning training dataset, but in an operational system? No thanks

If he wants to do ML research, why doesn’t he want to do a PhD program? I dont think you can get both: if you do research, there is less focus on making operational software. If you make operational software, there is less focus on doing research. Find out what you really want to do, and go with that.

Isomorphic as vector spaces, meaning that their additive structure is the same. But the complex numbers are usually not used as a vector space, but rather as an algebraic field, i.e. considering both their additive and multiplicative structure.

Would either of these database systems be proper for a case where you have a mix of large measurement data and small reference/master data that you need to join, filter, etc. ?Example:

SELECT r.country, m.time, SUM(m.measurement) FROM measurement_table AS m INNER JOIN refence_table AS r ON m.device_id = r.device_id

These are fine intros, but then you have to actually dive into these topics. Sometimes there is no real interesting way to explain these topics. Fx, iirc the construction of the real numbers is rather tedious. But I agree, that more effort could be done to motivate many of these topics (at least that was my experience studying math)

As another user wrote, some db systems already can provide suggestions for missing indexes based on stats. But automatically creating them? Should all new indexes just add up (that would fill the db pretty fast) or replace prevoius ones (what about users depending on these indexes?)

What? I wouldn’t want this. How would you evne automate it? Creating the right indexes is the same as creating the right tables and columns in your data model: It depends on the business purpose and usage of the data.

Did what exactly? Most the transmission grid at least is overhead lines in Denmark. In fact, it is said that putting more than 15% of transmissions lines underground would be irresponsible due to physical limitations of AC lines, which corrupts the transmission system.