[HN Gopher] SQL/SE Query Language Extension for Schema Evolution...
       ___________________________________________________________________
        
       SQL/SE Query Language Extension for Schema Evolution (1992) [pdf]
        
       Author : steve-chavez
       Score  : 27 points
       Date   : 2024-08-07 17:25 UTC (3 days ago)
        
 (HTM) web link (dl.acm.org)
 (TXT) w3m dump (dl.acm.org)
        
       | kthielen wrote:
       | I've always wondered why SQL doesn't support variant types, and
       | in this case especially.
       | 
       | If you're going to store a sequence of values whose type can
       | change over time, a variant is the obvious encoding choice. As
       | new schemas are introduced, you add constructors to the variant.
       | 
       | On top of that, you can apply some basic structural reasoning to
       | say eg a field can be indexed (possibly by different paths in
       | each case) iff it exists in each constructor, or optionally with
       | the awkward SQL nulls in case a field is not in each constructor
       | (as they describe in the paper).
       | 
       | But then you could also use general variant deconstruction to
       | decide on a case-by-case basis how to handle each version or
       | subset of versions of a schema, and having that capability to
       | represent variants in user data, independent of "evolving
       | schemas" could have significant general use as well.
       | 
       | If you feel like having tuples and variants is too complicated,
       | use dependent sigma types, so they're all tuples, and then your
       | schema language is much more expressive still.
       | 
       | It's weird how much database systems have stagnated on this
       | front.
        
         | layer8 wrote:
         | Adding variant cases effectively changes the type of a column,
         | breaking existing clients. So you might as well migrate the
         | existing data to a consistent representation.
         | 
         | Independently of schema evolution, a sum type can be
         | implemented by using different nullable columns, and adding a
         | multi-column CHECK constraint that (one and) only one of those
         | columns must be set. One might want more syntactic sugar in SQL
         | for that, but it would also complicate the language and data
         | model, without really adding any new functionality.
        
       | nyrikki wrote:
       | There was a recently published meta review on the subject of
       | Schema Evolution that is probably far more practical.
       | 
       | https://www.worldscientific.com/doi/10.1142/S297237012430001...
        
       ___________________________________________________________________
       (page generated 2024-08-10 23:01 UTC)