# Re: Mixing OO and DB

Date: Thu, 15 May 2008 14:06:48 -0700 (PDT)

Message-ID: <4f453cad-f273-485f-8d47-b560f80893ac_at_b1g2000hsg.googlegroups.com>

On May 15, 2:51 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:

> TroyK wrote:

*> > On May 14, 8:51 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
**>
**> >>Bob Badour wrote:
**>
**> >>>topmind wrote:
**>
**> >>>>Robert Martin wrote:
**>
**> >>>>>On 2008-03-09 01:02:47 -0600, Marshall <marshall.spi..._at_gmail.com> said:
**>
**> >>>>>>On Mar 8, 6:07 pm, Robert Martin <uncle..._at_objectmentor.com> wrote:
**>
**> >>>>>>>On 2008-03-06 15:37:56 -0600, topmind <topm..._at_technologist.com> said:
**>
**> >>>>>>>>>Each small group of classes becomes a little roll-your-own data
**> >>>>>>>>>access
**> >>>>>>>>>and manipulation scheme that is perfectly tuned for it's very
**> >>>>>>>>>specific
**> >>>>>>>>>purpose.
**>
**> >>>>>>>>Which is over-kill for the task-level.
**>
**> >>>>>>>Do you have proof that it's overkill? Do you have any objective
**> >>>>>>>measurements that it's overkill? Or it is just your own opinion. I
**> >>>>>>>mean, if it works for you that's great, but don't force your own
**> >>>>>>>opinions on everyone else <grin>
**>
**> >>>>>>This is a fallacious argument. You're proposing extra effort without
**> >>>>>>justification. The idea that, in the absence of evidence either way,
**> >>>>>>topmind's proposal of not putting in that effort is on equal footing
**> >>>>>>with yours doesn't hold. Extra effort requires justification. What
**> >>>>>>you are saying is, "hey, we don't know if this work has any value
**> >>>>>>or not, so doing it is just as justified as not doing it."
**>
**> >>>>>Go back to the root of the argument. You'll see that the initial
**> >>>>>premise is that the programmer organizes the data into a form that is
**> >>>>>more convenient for him to get his computational job done. So there
**> >>>>>*is* justification.
**>
**> >>>>Depending on how "convenient" is measured.
**>
**> >>>>Note that the effort to wrap SQL in methods is only one of the issues
**> >>>>against it.
**>
**> >>>>>>>It is very common for programmers to manipulate data into forms that
**> >>>>>>>are particularly convenient for the application they are writing.
**> >>>>>>>Databases are seldom in that form since (for one thing) they must
**> >>>>>>>usually serve many different and competing applications.
**>
**> >>>>>>(I'm going to just label the above as bogus without justification.
**> >>>>>>It's late and I'm lazy.)
**>
**> >>>>>That's fine. Consider, for example, an algorithm that finds the
**> >>>>>minimum spanning distance of a graph. (e.g. cheapest network route, or
**> >>>>>cheapest travel itinerary, etc). The node and edges of the graph are
**> >>>>>stored in database tables.
**>
**> >>>>>Shall we execute that algorithm by doing thousands of tiny queries as
**> >>>>>we walk from node to node through the edges? Or shall we query all the
**> >>>>>nodes and edges in one gulp, arrange them into a graph of objects, and
**> >>>>>walk through them that way?
**>
**> >>>It's interesting that the self-aggrandizing ignorant should mention
**> >>>minimum spanning trees. Creating a generic procedure for calculating
**> >>>minimum spanning trees in SqlServer is on my to-do list as I write.
**>
**> >>>If one studies the algorithms for minimum spanning trees, one quickly
**> >>>sees the task involves no traversals whatsoever. In fact, one generally
**> >>>creates the MST as a precursor to some sort of traversal, and the
**> >>>algorithms themselves are specified in terms of sets, which makes them
**> >>>ideal for implementing relationally.
**>
**> >>>At the moment, I lean toward Kruskal's algorithm. Mostly, I just don't
**> >>>understand Chazelle's algorithm well enough, and I don't have the
**> >>>patience to hunt down the remaining details. Plus, it is difficult to
**> >>>tease out how Chazelle's approximations might interact with dynamic cost
**> >>>functions.
**>
**> >>>The algorithm relies on a disjoint-set structure, which is just a tuple
**> >>>really. One would start by initializing a set of these structures with
**> >>>an element for each vertex. Hmmmm... a set of tuples... hmmmm... I
**> >>>wonder what sort of variable I could use to hold a set of tuples... I
**> >>>think I will use a relvar.
**>
**> >>>For a general solution we need to associate a cost with each edge.
**> >>>Hmmmm... an edge and a cost... hmmmm... I think I will use a tuple for
**> >>>each of those and a relvar for the entire set once again.
**>
**> >>>For the result, we need a set of edges. I think I will use a relvar for
**> >>>that too.
**>
**> >>>Once we initialize these relvars, the algorithm is quite simple:
**>
**> >>>While our edge-cost relation has at least one tuple:
**> >>> Choose one of the edges with the minimum cost.
**> >>> Perform a disjoint-set union on the two vertexes joined by the edge.
**> >>> Insert the edge to the MST result relvar.
**> >>> Delete all edges from the edge-cost relvar
**> >>> where the disjoint-set find places them in the same set.
**> >>>Done.
**>
**> >>>The general solution on my to-do list is a little more complicated
**> >>>because the cost function can be dynamic. There has to be another step
**> >>>in the loop to re-evaluate the costs for any edges where the cost might
**> >>>change.
**>
**> >>>[topmind's somewhat less informed response snipped]
**>
**> >>The Delaunay Triangulation code was more complex (proper domain support,
**> >>which SqlServer lacks, would have helped), but the Voronoi Tessellation
**> >>code could be as easy as a view. Lloyd's algorithm for k-means
**> >>clustering was rather straightforward in t-sql once I had the delaunay
**> >>and voronoi code in place.
**>
**> >>My to-do list is now void of computational geometry stuff for the time
**> >>being. Sigh.- Hide quoted text -
**>
**> >>- Show quoted text -
**>
**> > Bob;
**>
**> > Quick question - which version and edition of SQL Server are you
**> > working with? Although not proper domain support as you note, the
**> > ability to create user-defined functions using the integrated CLR of
**> > SS2K5 may get you "close enough" to make for some fairly clean T-SQL
**> > expressions. Is this the route you went?
**>
**> > I'm wikipeducating myself on the Dalaunay triangulation and related
**> > topics right now. This is pretty fascinating stuff, and interestingly,
**> > ties directly to some topics in a linear algebra class I'm currently
**> > taking.
**>
**> > TroyK
**>
**> SQL Server 2K SP4
**>
**> I make heavy use of temporary tables and for some strange reason one can
**> neither pass tables as parameters nor reference temporary tables from
**> user-defined functions.- Hide quoted text -
**>
**> - Show quoted text -
*

SS2K8 (upcoming) introduces table-valued parameters. It must have been a difficult feature, because I know developers have been asking for them for a long time.

TroyK Received on Thu May 15 2008 - 23:06:48 CEST