To MySQL or Not SQL

[Stephen Barncard]

I've been up and down with this 'to SQL or not SQL' thing for a 
while, fearing long monotonous nights debugging arcane commands and 
crashing, etc. which has been my experience with client server 
databases used with x-talks in years past. Remember "Butler"? Holy 
smoke, what a crashfest. Not helped by system 7's ODBC implementation.

I've painfully worked with GoLive 6's amazing but buggy Dynamic 
feature, which allows you to create webpages that suck data from 
MySQL and others. It writes php or asp snippets to the web page as 
well as install a few subroutines on your site.  Brilliantly 
executed, to a point, except it looked like they just ran out of 
money and stopped beta testing and debugging. Out it went, and with 
only one bug fix version (the first version wouldn't work at all) 
that was it, in typical Adobe fashion. "There are no more bugs in 
this product." So I had to tough it out with the unfamiliar PHP code 
calling SQL from html. Pretty crazy. But one thing in all my 
struggles was constant: my MySQL server hosted at Dreamhost.

I gotta tell ya, if you guys don't have an ISP that includes mySQL, 
python,perl,mysql, quicktime streaming on a Linux server... move!!

This stuff works, and one of the benefits of my particular webhost is 
that MySQL is part of the deal. They maintain it, and you secure it, 
put data in, and use it. For $10/month! Why bother running one's own 
server for most projects if installation is painful?

But, getting to the point, I recently started a project that included 
a client-server function and I felt that this might take a while to 
get running. I actually tried to make a 'mock-database' in globals 
thinking it might allow me to get on to the other parts of building 
and come back to it; you know, hook it up later.

Well I was debugging pretty much what would start to look like SQL 
calls anyway, so I just scrapped it and was determined to do it the 
'right' way. I got Sarah's fine SQL stack, which demonstrates some of 
the built-in SQL functionality of Rev, with a very nice layout and a 
simple dislplay of data that I hadn't seen before -- thanks for the 
idea..and it inspired me to just dive in.

Still I needed a bit more functionality and ease...too many things to 
open and close, cleanup etc..  THEN.. after a tiny bit of searching I 
found Trevor Devore's libDB... finally, a simple, logical way to deal 
with database calls. And it works, fast and clean. And all based on 
Rev arrays.

Yesterday, I reached a milestone in my project, I got a moderately 
complicated multi-call SQL report working...and it took about 2 weeks 
after I decided to go for the 'real deal'.

So I'd say, if your project can use client-server functionality now 
or in the future, do it! Use Chipps altMYSQL lite if it's imbedded. 
It just works and saves time for other things, like the interface!

SQL itself is pretty easy as a language. It's verbose, self 
describing and consists of 40 or so commands that all make sense. 
Sometimes it's almost like Transcript! You usually only need to know 
a few commands to get a listing or a single record. It's a little 
more involved to insert and create records, but not much with 
Trevor's lib.  And if the data doesn't need to be entered much, one 
can always manage the data input side with a SQL client such as 
CocoaMySQL and many others. I save various SQL calls in custom 
properties to avoid a lot of the quoting problems, and Trevor's lib 
also cleans up the entered SQL calls.

Speaking of verbose, I'll stop. Sorry for the long post.

stephen quinn barncard
(sqb)




>Hi Kurt,
>
>>I know that there are probably those for whom working with SQL is a 
>>piece of cake; in their eyes I'm probably making things much more 
>>difficult for myself that they need be....
>
>A project I was working on started down the SQL road and hit a BIG 
>bump with the first book on actually setting up and administering an 
>SQL network on Mac OS X.  Do you like Unix command line syntax, aka 
>Apple's Terminal application?  Would you like to walk users through 
>it over the phone as part of your support effort? Do you want to 
>predefine every data field to the database...and assign