dagheti

Duplicate values that should be unique is such a common problem if you don't use constraints.

This is a good example of why ACID and declarative constraints are a very good idea for data management.You can do a bad delete from query if you don't have the proper safeguards (though querying ability of SQL lets you more easily preview your changes), but the initial corruption of the data is an easily avoidable problem.

ACID isn't a banking issue, it's an issue in any database where data integrity is important. Having written administration software for life insurance companies, you can be sure that we designed our software to rely on ACID semantics.

Without transactions, correctly writing the software would have been far more difficult, especially in situations where you need to rollback a transaction that is partially completed because of system errors.

Caring about branding things NoSQL isn't just not useful, it's harmful because it replaces really understanding things (like how a particular method works, and what it's good for) with a useless shorthand. Reminds me of a quote:

“You can know the name of a bird in all the languages of the world, but when you’re finished, you’ll know absolutely nothing whatever about the bird… So let’s look at the bird and see what it’s doing — that’s what counts. I learned very early the difference between knowing the name of something and knowing something.”

R. Feynman - "The pleasure of finding things out" 1981

I believe they are using SQL server, which keeps statistics on the most longest total runing, and longest per-run queries. It's a good idea to monitor this list and take a very close look at every execution plan that comes up. Many times you end up doing RID lookups due to non-clustered indexes that don't cover the requested data.

The name relational model is quite unfortunate, as it leads to confusion about what the model is (not much to do with 'relationships').

The key concepts are using sets to store data (making you think about your data in a way where duplication of tuples and orderings don't mean anything), and always using values instead of pointers to store your data and references.

I think that these concepts are very useful when it comes to managing data, but they seem to get lost in the all the talk about "relationships" and "sql" and "structured tables".

At least most of the time people stick to the Turing incomplete subset of the language.

One of the joys of working in F# is how the stronger type system combined with the type hover-overs allows for a sort of debugging-as-you-type that allows you to think with the help of the type system. It really helps unwind difficult problems and when there are errors you can easily see inline how to fix them. This is an impressive use of that facility, though it's even more useful when trying to solve a problem.

Oh I agree they are both very bad. Putting NULL in a non-NULL field is totally wrong.

However I really do think that inserting an unexpected default value is worse than inserting NULL into a NON-NULL field. The NULLs will cause problems, but they are problems you can see and resolve.

The default values are silent errors that will corrupt your data and be very difficult to recover from in the future. You can only guess which data was wrongly inserted.

Inserting a default value is even worse than inserting NULL. Now you can't tell what data was wrongly inserted if you tried to clean up the mess later.

I find that F#'s (close to OCaml) type system helps me think through problems and lets me get correct programs faster, that somehow just seem to work correctly the first time.

Usually when writing a program in F# I usually write out the types of the functions I need first, before worrying about how the functions work. Because the type system is so descriptive I can validate that a plan to solve a problem is going to work before I start writing code.

Because the type system is powerful, when I need to make a change, it is simple to determine where my assumptions are broken and make the correct fixes.

This is true only if we accept that AI trading is actually making the market more efficient. The 'wisdom' of crowds is often foolishness, and this could be even more true for a crowd of computers.

It is very possible that by using AI that looks mostly at numbers for trading is just destabilizing by relying too heavily on specific variables (the ones the algorithms can actually use as inputs) , and reduces efficient allocation of capital.

The pipe operator in F# |> is used in this way. When combined with currying it is especially effective:

  let double_then_sum a_list =
      a_list
      |> List.map  ((*) 2)
      |> List.fold (+) 0

I recently was tutoring a high school student who was instructed in their data-management course to create several graphs from the same set of data, comparing rainfall in different Canadian cities.

Unfortunately this data didn't make any sense to be plotted as a line-graph, a bar-graph, a histogram and a pie chart, as the comparisons didn't make sense for any but the bar-graph. It was if the students were actively being taught how to use graphs incorrectly. Creating pie charts when the entire pie doesn't mean the whole of anything I think was the worst culprit.

The key question is "Why" that needs to be asked. A customer may think they want to sort, select, and aggregate the data, but fundamentally "get the data" is very rarely the real reason for doing something.

That data is used to make a decision, and it's important that developers seek to understand exactly what that decision needs. Your users will often walk their way into a bad solution to their real problem because they will use their (incomplete) understanding of what is available.