1. 22

  2. 3

    you can’t join two tables containing the same field name without joining on those fields

    Heek! Foreign keys are how to naturally join tables.

    1. 3

      This restriction isn’t an intrinsic problem, I just haven’t gotten around to a solution yet. I implemented natural joins first because they were the most interesting to implement, not necessarily because they are the most useful kind of join. :)

    2. 1

      This is super neat! I’ve been writing a lot of T-SQL recently and though I appreciate the database aspect, I feel like the abstraction powers of the language leave a lot to be desired. Composition and reusability has been my greatest desire, but I’ve also wondered what the best way to make SQL testable might be. It doesn’t feel like testing is something that can be done inside the system very easily/idiomatically. Rather, you need some sort of runner to handle it.

      Some level of parameterization would be nice too. I had to write a lot of SQL that was using introspection and string concatenation, which is pretty janky. (Potentially a major security vulnerability too!) Being able to handle these operations in a safe way would be lovely. (Thinking of hygienic macros vs c preprocessor.)

      On the other hand, I have also wondered whether a really expressive database language is actually a trap. If it’s expressive then you might be inclined to do more processing in the database, which could lead to worse performance.

      Any thoughts on dumb vs smart data stores?

      Noticed that this is written in Haskell. Have been wondering what a relational database with sum types might look like. Not really applicable to this since it is a transpired language, but would be a nice feature when working with such languages.

      This blog post handles some patterns for working with sum types in SQL:


      Does anyone know of any database systems that work with sum types natively?

      Apologies for rambling! Typing this out on my phone while waiting to eat. Girlfriend just got home so little time to revise!

      1. 2

        I’ve worked quite a bit with T-SQL in the past and I found that using the WITH statements and views to wrap the more dirty things that are occasionally needed for performance, the majority of queries can be kept short and easy to understand.

        For testing, I had two different principles I used.

        The first was for verifying that the query worked as expected. I used a WITH statement, wrapping the whole query and supply the data needed.

        This doesn’t test for performance. I did that by creating a test instance of the database and doing tests in transactions that were never committed.

        1. 1

          Some level of parameterization would be nice too.

          I think you might mean something different, but you can pass parameters in to the queries. Search for ‘export’ in the readme.

          On the other hand, I have also wondered whether a really expressive database language is actually a trap.

          I am very much on the pro-database side when it comes to writing apps. IMO performance issues are better solved by thinking about your data rather than arbitrarily putting a network connection between your data and your app, and in fact that can often make things worse (e.g. N+1 queries).

          testing… sum types…

          I am kicking the can down the road on these subjects :)