More on Wide SQL Tables

[Noel Weichbrodt]

As a small followup to the earlier discussion in July regarding wide
(eg many-column) SQL tables, I have a case where it a large, 43-column
table would sensibly decompose into a couple smaller representations.

Two ideas for representing this decomposition in scalaquery seem
appropriate:

Separate tables keyed off the same id, eg
Table1 extends Table("commontable")
def id = foreignKey(Table2 id)
def uniquecolumn1

Table2 extends Table("commontable")
def id = primarykey
def uniquecolumn2

and thus access to uniquecolumn1 would be done through an implicit
join on Table2.

Parent/child, eg
Table1
def uniquecolumn1

Table2 extends Table("commontable")
def id = primarykey
def uniquecolumn1
def table1 = Table1

and thus access to uniquecolumn1 would be done through a method on
Table2, eg
Table2.table1.uniquecolumn1

I'm unclear how to represent the parent/child approach in scalaquery.
If I'm using case classes to represent those decompositions, what's
the simplest way to represent them to ScalaQuery?

Regards,
--Noel Weichbrodt

[David Portabella]

you can also recompile scala, and change the maximum number of fields
for a Tuple (22 by default).

On Nov 10, 11:55 pm, Noel Weichbrodt <noel.weichbr...@vsolvit.com>
wrote:

[Noel Weichbrodt]

Hm, didn't know that the tuple limit was not a data structure
limitation, thanks!

Still seems suboptimal because a) rolling my own scala version isn't
conducive to easy maintenance and b) the table does logically
decompose to two < 22 column objects. A solution that utilizes that
decomposition would be preferable.

--Noel

On Nov 10, 5:13 pm, David Portabella <david.portabe...@gmail.com>
wrote: