Re: [Haskell-beginners] Ranges and List Comprehensions in SQL
On Fri, Sep 03, 2010 at 11:21:27AM -0400, Tom Murphy wrote:
I am not sure I understand what you are asking. Do you want something like this?
data Range = Range Integer Integer
toRanges :: [Integer] -> [Range] toRanges = ...
toRanges should not be too hard to write but nothing like that exists as far as I know.
I don't quite understand the functionality of toRanges. When I say "range," I mean a list containing an enumeration, in the form:
[2..300]
[2..300] is just syntactic sugar for the list [2,3,4,5,6,7,8,9,......,300]. It isn't actually a real "thing" in Haskell. That's why I made a new data type to represent it: data Range = Range Integer Integer toList (Range x y) = [x..y] So for example (Range 2 300) represents the list [2..300].
The record would actually be coming from an SQL database. I would like to be able to store a large list in SQL records, without having to store every element.
I see. So the question seems more about database design than about Haskell. Toby has suggested a more relational way to model the data, but his solution does end up storing every element. But you could do something more like CREATE TABLE tv_show ( id INTEGER NOT NULL, -- etc title VARCHAR(80), PRIMARY KEY (id) ); CREATE TABLE episode_ranges ( tv_show_id INTEGER NOT NULL, start_episode INTEGER, end_episode INTEGER PRIMARY KEY (tv_show_id, start_episode) ); Or something like that (it's been a while since I've used SQL). The data would then be more like tv_show (30, "The Simpsons") episode_ranges (30,1,4), (30,14,14), (30,18,21), (30,23,25) -Brent
On 3-Sep-10, at 11:43 AM, Brent Yorgey wrote:
On Fri, Sep 03, 2010 at 11:21:27AM -0400, Tom Murphy wrote: ...
The record would actually be coming from an SQL database. I would like to be able to store a large list in SQL records, without having to store every element.
I see. So the question seems more about database design than about Haskell. Toby has suggested a more relational way to model the data, but his solution does end up storing every element. But you could do something more like
CREATE TABLE tv_show ( id INTEGER NOT NULL, -- etc title VARCHAR(80), PRIMARY KEY (id) ); CREATE TABLE episode_ranges ( tv_show_id INTEGER NOT NULL, start_episode INTEGER, end_episode INTEGER, PRIMARY KEY (tv_show_id, start_episode) );
This is a possible alternative, but you would need something like a CHECK constraint as well, for overlapping ranges. The primary key definition above isn't doing much for integrity. I see no downside whatsoever to "storing every element". It's what an RDBMS does: manage relations. --Toby
Or something like that (it's been a while since I've used SQL). The data would then be more like
tv_show (30, "The Simpsons") episode_ranges (30,1,4), (30,14,14), (30,18,21), (30,23,25)
-Brent
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners
On Fri, Sep 03, 2010 at 12:09:01PM -0400, Toby Thain wrote:
On 3-Sep-10, at 11:43 AM, Brent Yorgey wrote:
On Fri, Sep 03, 2010 at 11:21:27AM -0400, Tom Murphy wrote: ...
The record would actually be coming from an SQL database. I would like to be able to store a large list in SQL records, without having to store every element.
I see no downside whatsoever to "storing every element". It's what an RDBMS does: manage relations.
Good point. I initially meant to write something about "premature optimization" in my email but then forgot. -Brent
participants (2)
-
Brent Yorgey -
Toby Thain