On Jul 30, 9:41 pm, Paul F Fraser <[email protected]> wrote: > Jeremy Evans wrote: > > I'd suggest just adding a subclass of Sequel::SQL::Expression. Maybe > > supporting an API like: > > Jeremy, > After delving a little deeper into handling hstore in sequel, the > changes are far from trivial, for me, anyway. > It seems to me that a simpler approach might be to just have a > conventional pg table with k & v columns with the row(s) linked to the > parent table. > This of course, would be easily handled by sequel without any changes. > Do you think implementing hstore would have any worthwhile advantages > over this simpler approach?
The queries you will have to write to find entries based on multiple keys/values (i.e. key1 = value1 AND key2 = value2) are quite ugly/slow if you use that approach, since you have to use subselects or INTERSECT. The queries would probably be much nicer/faster with hstore. If you aren't doing anything involving multiple simultaneous keys/values, then that approach doesn't have that many drawbacks. So it really depends on your querying needs. There's also differences when inserting/updating/deleting, but it's hard to comment about those without knowing your database schema. Jeremy --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sequel-talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en -~----------~----~----~----~------~----~------~--~---
