semanticscuttle-devel

Re: [Semanticscuttle-devel] SQL Calls

[Christian W. <cw...@cw...>]

Hi Mark,


> I've read a couple people state they've had performance issues with
> larger installs and that you've prototyped some updates to the SQL
> calls to possibly fix the issue.  One of my strengths is db calls and
> would love to take that if you like.  I've got tons of Oracle
> experience and have noticed that some of the SQL calls aren't Oracle
> friendly (i.e. LIMIT, LIKE, etc). Granted I don't think most of our
> user base will be using Oracle, but would LOVE to taunt that as an
> option.  :)

What's the state of the private feed link? I'd like to see this
finished first.

Regarding the SQL calls: I don't like AdoDB that is used in
semantiscuttle currently, and would rather switch to PEAR's MDB2 or
plain PDO. MDB2 does real abstraction but is PHP4 (thus not E_STRICT
compatible), whereas PDO does not really do any abstraction but is
available in PHP itself and fast.
Do you have any preferences?

When I tried to fix the issue with the huge number of bookmarks, I had
to dive really deep in SQL generation. Fixing the DB layer first would
be better in my eyes, because it would perhaps ease the later
optimization.


> My db doesn't have 30k of links, but I can easily dump
> an ton of dummy links in there.
There is a dummy-bookmark generation script in scripts/, maybe it helps.

-- 
Regards/Mit freundlichen Grüßen
Christian Weiske

-= Geeking around in the name of science since 1982 =-

Re: [Semanticscuttle-devel] SQL Calls

[Christian W. <cw...@cw...>]

Hi Mark,


> > What's the state of the private feed link? I'd like to see this
> > finished first.
> Agreed, hope to have this done shortly.  Got into cleaning up code
> which helped me get more familiar with the code.  My desire is to
> have it completely tested by the weekend (depending on my schedule).
No need to rush, it's a spare time project :)


> > Regarding the SQL calls: I don't like AdoDB that is used in
> > semantiscuttle currently, and would rather switch to PEAR's MDB2 or
> > plain PDO. MDB2 does real abstraction but is PHP4 (thus not E_STRICT
> > compatible), whereas PDO does not really do any abstraction but is
> > available in PHP itself and fast.
> > Do you have any preferences?
> This is a tough call because it depends on where our focus is.  We can
> certainly go with PDO which is a great standard and has little
> overhead. The downside is that to support multiple databases would
> require altering the SQL commands based on the database type.  An
> alternative is something like Active Record (Propel, Doctrine, etc)
> where everything is contained in the class.  The downside to AR is
> that it has a huge overhead and requires bytecode cache to maximize
> performance.  So the question is, what is our focus: do we focus on
> having less overhead with PDO and refining what db's we support or go
> with Active Record?  I personally think that AR may have too much
> overhead than what we really need (but would be really cool).

I would also prefer PDO since it's fast and doesn't have much overhead.
An ORM is too large for us IMO. So let's go with PDO.


-- 
Regards/Mit freundlichen Grüßen
Christian Weiske

-= Geeking around in the name of science since 1982 =-