Database Comparison?

[democratix]

Hi,

I've only got a couple years experience developing for Access but have
recently been experimenting with HTML/javascript for gui and
client-side scripting, mysql for database and php for server-side
scripting. I've been running it all on the development machine until
the application I'm building is advanced enough to start
optimising/testing with network lag in mind. So it's no slower, and in
some ways at least it seems faster.

Has anyone had much experience with both? If so, what are your
relative opinions of the two packages if used for the same purposes? I
haven't made up my mind as to convenience overall since the web-based
app hasn't been deployed to any users yet (although I can imagine that
will be simpler, since people just need to connect to an ip address),
but a few advantages I have noticed in developing it include:

- Less confusion due to separation of components.

While I thought it might make things more complicated, it seems clear
after using it that php is built more than anything to easily sit on
an apache server, talking to a mysql database and spitting out html to
a web browser. That makes sense I guess since php is made only by its
users and that's what most people seem to use it for. The actual
advantage to separating the components is you know where the problem
is. If you get an error in the javascript console, it's a javascript
error, if it's in the browser it's php, unless it's in the database,
in which case it says it's a mysql error. Given how unintuitive
error-messages often are for any programming tools, knowing where to
start at least, is nice.

Besides debugging myself, it also makes it easier to find posts on the
net from other people who have had the same problem. Which brings me
to...

- Developer discussions on the internet include more people with
access to the source code.

So bugs or problems in the tools themselves often prove less obscure,
if they haven't already been fixed. I've never personally inspected
the source code of any of the programming tools I use unless I've
written them myself, but when you go on the net looking for fixes or
workarounds, a lot of people have. This could be my psychological bias
towards the ideals of open-source software, but it does seem that
mysterious quirks which, even when you fix them, make no sense; are
less common.

- Less risk of future incompatibility.

Web browsers, to take one obvious example, seem to be more compatible
with things written for older versions of themselves, than microsoft
access is. Sometimes the automatic upgrade of your mdb will work, but
often you need to make a lot of code changes to support a newer (or
older) version of access, and in the worst case it's much easier to
have two web browsers running on your machine if you need, than it is
to have two versions of Access.

Maybe there are more advantages. As for disadvantages I thought I
would miss the form designer, and in some ways I still do, but
html/js/php are very versatile, and in the process of learning how to
use these things better I've made a rudimentary gui designer and some
templating functions, which allow fairly easy manipulation and reuse
of gui components.

Another fear I had was the lack of functionality, especially since
html has a much smaller widget set than access forms (although I guess
it's always possible to use xul instead and then distribute firefox to
all the users), but that problem seems much smaller now, especially as
I learn more about javascript's abilities. There are definitely some
things html/js/php can do which access forms and vba can't (or not as
easily), some of which seem useful, but as to what practical
importance all these differences will make, that remains to be seen.

Oh and also there are a lot more easily accessible examples of
creative/clever ways of using this combination of tools since it's
what many (most?) web developers use, so you can just look at a bunch
of websites to get ideas for how to best achieve what you want.

Comments?

 

[Nikolai Chuvakhin]

(e-mail address removed) (democratix) wrote in message

I've only got a couple years experience developing for Access but have
recently been experimenting with HTML/javascript for gui and
client-side scripting, mysql for database and php for server-side
scripting.

Has anyone had much experience with both? If so, what are your
relative opinions of the two packages if used for the same purposes?

Bad idea. The purpose should dictate the choice of architecture.
Desktop database applications should be used when the number of
concurrent users is relatively small, users are not dispersed
geographically, and system environment on the client machines is
in control of the individual(s) deploying and maintaining the
application. Web-based appications, in contrast, shine when the
user base is large and geographically distributed, and availability
of thick client or system resources sufficient to run it are not
guaranteed (for example, there is a random Mac among a bunch of PCs,
or the system must be PDA-accessible).

Also, it is helpful to remember that the two architectures are not
mutually exclusive. It is entirely possible to have two (or more)
interfaces to the same server application. Take a look at Exchange
Server or Act!, for example. Both are accessible via a thick client;
both have extentions allowing to access them via a Web browser...

Cheers,
NC

 

[Albert D. Kallal]

Has anyone had much experience with both? If so, what are your
relative opinions of the two packages if used for the same purposes?

I don't really understand your question here? Why not compare vb.net to
those tools?

Or, why not compare your tools to Delphi?

The problem I see here is that you talking about ms-access, which is a forms
development tool, or rich UI tool for the windows desktop. Ms-access is
not even a database, but only a tools that lets you connect to a database
engine of your choice (Oracle, Sql-server, MySql, JET, etc).

The set of tools you are talking about are database servers, web
servers, both of which are not related to ms-access at all?

Ms-access is not a database, but only a tool that lets you connect
to a database of your choice.

- Less confusion due to separation of components.

If you mean you are using tools that are less integrated, have less
features,
and take FAR more work and developer time to do simple tasks, then I can
understand the less confusing part!

I can't imagine you find ANY degree of productivity in automating standard
business tasks on the desktop without using the "glue" or so "com" objects
that a rich windows environment gives you. Comparing web based development
tools to rich user desktop automation tools like ms-access don't make sense
all? Ms-access is a RAD tool, and good one at that. You can build a report
of customers. You can then build another report of customer invoices. So
far, we got two nice reports, and have not had to write one line of code
yet. Now, we want to display the customer info, and then display a list of
customers invoices for EACH customer. Well, you just drop in the invoices
report into the customer report. So, now, you got a sub-report. You
instantly crated a one to many join, and classic one to many report.
And again at this point I have not yet written one line of code. In fact, I
don't even have to write the sql to join the two tables, since ms-access
will set the link-master, and link-child fields for you when you drop in the
invoices report onto the customer report.

To create the same things in
PHP and MySql..you are talking about a LOT of work here (many hours).
And, in my example,
the customer info like address etc. DOES NOT repeat, and the sub-report thus
will show each invoice for the customer record. This incredible complex task
takes LESS then one minute of work. Such tasks with MySql and Php take
REAMS and REAMS of code and work to do. At min, we are talking
about something that is at least 30 to 60 times more efficient in terms of
developer time. I mean, you are talking about one of the best report
writers that money can buy. Your tools are not for writing reprots!
So, this kind of task will take you tons of work with your tools!

I mean, this is like
comparing writing some calculations in Delphi vs using Excel? The
accountant guy down the hall don't need to learn Delphi to build a
spreadsheet. So, we are taking "end" user data tools vs web
development tools..and they could not be farther apart. If you are
looking for something to compare, you need to start looking at
..net and web services.

By the way, here is an interesting discussion I just had with someone
looking for a reporting solution:

http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=173188

Of course...access is a hot knife through butter for the above...

I just want to point out that your comparisons of these complete different
tools does not make sense. If you are telling me how easy it is to server
out some
web pages with Apache..then you got a great point here. Apache is a
wonderful web server. In fact, it remains a market leader today.
However, tools like PHP and Apache bear NO relationship to a RAD tool like
ms-access for users manipulating data on a rich desktop on windows.

When I talked about "com", I was taking about how software and programming
talk to each other. So, how about you take that above report that slices
and dices the classic one to many join problem, and attach it as a email,
and
then allow the user to enter additional comments before you send the email?
Once again, this takes...what 2 or maybe 3 lines of code in ms-access? While
you are at it, generate a word merge..and attach that also. Once
again, with the tools you mention, you are talking REAMS and REAMS of code
(oh, yea...forgot...you are not using a rich email client). If you ever
developed
software..and the person says...I need to email that repot at the press of a
button...along with a price list..you now start to realize what automaton
means.

Again, this comparison don't make sense, and since this post is crossed over
to the php newsgroup, then again, I am sure readers there are just as
confused
also! So, to all the PHP and Apache lovers, this whole thing is not a grade
2 my languages is better then yours! (we stopped that child like stuff of
Ford vs Chevy years ago in grade school....right!).

The right horse for the right course
is what we are taking about. I would be insane to use ms-access
over PHP and Apache for a web application. ms-access is not even
in that game! Apache is real killer in this regards.

- Developer discussions on the internet include more people with
access to the source code.

You mean code examples? There is likely as many VB examples on the web with
source code as there is PHP, in fact .likely a LOT more, and 99% of these
examples
include the source code that I seen.

- Less risk of future incompatibility.

Why, on what grounds do you base the above? You obviously have not been
around software enough. Just look at apache? What version are you using? I
bet you are using 1.3.x version, and not a 2.x version? yet. How come?
Apache 2.0 came out in what...mid 2002 (2 years ago!!). The failure and lack
of adoption rate of apache 2.0 is likely one of the largest software
failures in our industry. The REASON why people are sticking with 1.3.x
version is because difficulty of using their existing code library when they
move to 2.0.
(this was a big boo boo, and shows that these projects are not immune to
changing
how things works...and breaking things!).

So, what is stopping a bunch of developers at their own
whim tomorrow to deciding and modify a bunch of code that breaks
compatibility? What is stopping them? The apache folks learned this
lesson the hard way. Fact is, when companies like
MS breaks software, it cost them money! That is why
you can still run a 24 year old spread sheet on a brand new windows box.
(the 1981 version of Visi-Calc, the first spreadsheet STILL runs on a brand
new PC today). MS could ONLY sell windows NT to consumers when
they added windows 3.1, and dos compatibility. the results of the new
windows NT is called XP. MS tried for years to get consumers to use
NT, and ONLY after making it compatible with win9x, did it fly.

So, it seems to me that the stakes are FAR more serious
for commercial companies to maintain software compatibility then a bunch of
people sitting around and adding new features. There is NOTHING
stopping developers of the tools you mentioned from coming out with
a new version that breaks compatibility (my Apache 2.0 is likely the
best example of this).

Sometimes the automatic upgrade of your mdb will work, but
often you need to make a lot of code changes to support a newer (or
older) version of access,

Hum, the upgrade process has been good. In fact, from access 97 to access
2003, I have converted some large projects, and the applications converted
flawlessly with no problems. Further, it is in the interest of MS to make
sure
this process goes well, as it makes a difference in their bottom line. They
NEED customers. So, that is why Microsoft has released a nice upgrade tool
to
help you migration older ms-access programs to the new one.
The follow link has a cool screen shot and a link to download this free
tool here:
..
http://www.microsoft.com/office/ork/2003/journ/accessconvert.htm

And, by the way, that cool above application has the source code is
included.
(already learned some interesting coding ideas from that application!)

and in the worst case it's much easier to
have two web browsers running on your machine if you need, than it is
to have two versions of Access.

Well, in fact, with access2003, I can create access97 files. So, from a
version point of view, ms-access is very good now. I installed ms-access
a2003, and was able to delete 3 previous versions of ms-access all on one
slice. I don't think ms-access has even been better. Further, if you want,
you still can run a 10 year old version ms-access on your pc anyway.

I learn more about javascript's abilities. There are definitely some
things html/js/php can do which access forms and vba can't (or not as
easily), some of which seem useful, but as to what practical
importance all these differences will make, that remains to be seen.

You mean things like sub-forms that automatically handle the parent to child
relationships? You mean things like combo boxes that allow multiple
columns, allow display of a description text, but stores the id, and also
has
nice features like "not in list" to help you add new entrees to the comb
box? How do you code a "not in list" event? Oh, ..right you don't have
that event (again...start writing reams of code!). I could go on and on

You can read up on my views on sub-forms here:
http://www.attcanada.net/~kallal.msn/Articles/fog0000000005.html

Oh and also there are a lot more easily accessible examples of
creative/clever ways of using this combination of tools since it's
what many (most?) web developers use, so you can just look at a bunch
of websites to get ideas for how to best achieve what you want.

There is an INCREDIBLE number of ms-access examples on the web, and further
99% of them include the source code.

If you are looking at Java, then you really want to start looking at the
..net framework. Further, in terms of web services and the new software
development demands, your choice of web server don't compare to the .net
frame work of web services. So, if you are looking to compare something in
the web space of things...don't look at ms-access!...You need to be looking
at .net if you start talking about java.

I used to frequent some of the MySql discussion groups, and the quality of
help, and frequents of posts seems to have been dropping in the last year.
Perhaps it is just me, but I don't see the user community nearly as active
and helpful as it used to be. (this is my humble opinion here!!).

Right now, with ms-access we see about 1000 posts in ONE day!. That works
out to about 30,000+ posts are made and answered in one month.

I don't accept the fact that Ms-access lacks anything in terms of the
on-line user community and help. In fact, I would state that the ms-access
on line community and help resources is likely the best on the web compared
to ANY software product. I repeat ANY software product.

 

[democratix]

I don't really understand your question here? Why not compare vb.net to
those tools?

Or, why not compare your tools to Delphi?

The problem I see here is that you talking about ms-access, which is a forms
development tool, or rich UI tool for the windows desktop. Ms-access is
not even a database, but only a tools that lets you connect to a database
engine of your choice (Oracle, Sql-server, MySql, JET, etc).

The set of tools you are talking about are database servers, web
servers, both of which are not related to ms-access at all?

Ms-access is not a database, but only a tool that lets you connect
to a database of your choice.

I apologise if I was unclear, basically I'm rewriting an application
(business-managment db+interface) using:

HTML/JS for the gui, where the old version used MS-Access forms,
PHP as a substitute to VBA for validation and business logic, and
MySQL instead of Access' native encapsulated MDB database.

That's why I was wondering about other people's experience with using
these very different tools for the same or similar applications.

(Not decided yet on reports, probably html or pdf).

 

[Nikolai Chuvakhin]

I can't imagine you find ANY degree of productivity in automating
standard business tasks on the desktop without using the "glue"
or so "com" objects that a rich windows environment gives you.

Imagine a geographically distributed organization, or one with mixed
(PC/Mac/Unix/PDA) hardware base, or one that needs to make data
available to outside users (customers, suppliers, regulators, etc.)
on demand. The richness of Windows environment all of a sudden becomes
a luxury, unaffordable and unnecessary...

Comparing web based development tools to rich user desktop automation
tools like ms-access don't make sense all?

You are making an assumption that automation must be desktop-based.
This is not always the case, as I was trying to point out to the OP
earlier.

Ms-access is a RAD tool, and good one at that. You can build a report
of customers. You can then build another report of customer invoices.
So far, we got two nice reports, and have not had to write one line
of code yet.

Great, no questions about it. Now let's say a customer wants
to see his account statement online. Oops; the desktop assumption
just proved inapplicable...

To create the same things in
PHP and MySql..you are talking about a LOT of work here (many hours).

You are probably right, but the customer will be able to see his account
statement online. You'll never be able to furnish data on demand to
remote or outside users, if you stick to the desktop paradigm...

I just want to point out that your comparisons of these complete different
tools does not make sense.

Not necessarily. The comparison definitely makes sense in terms of
what kind of situation dictates which approach...

tools like PHP and Apache bear NO relationship to a RAD tool like
ms-access for users manipulating data on a rich desktop on windows.

Exactly. So first, we need to understand which goal -- accessibility
of data or richness of interface -- is more important for the application
in question, and then act accordingly...

how about you take that above report that slices and dices the classic
one to many join problem, and attach it as a email, and then allow the
user to enter additional comments before you send the email?

Sure, and, since the report is saved as an RTF, the user can modify it
before sending it out, which is not always desirable. How would you
like to invest your money with an adviser who can manually modify your
account statements? The question, unfortunately, is not hypothetical;
a few years back, Ben Affleck, Courteney Cox, Matt Damon, Leonardo
DiCaprio, Cameron Diaz, Ben Stiller, and a bunch of other people lost
about $10 million partly because their investment advisor, Dana Giachetto,
was forging their account statements left and right, so he was able to
disguise misappropriation of funds for at least five years...

Cheers,
NC

 

[Albert D. Kallal]

Imagine a geographically distributed organization, or one with mixed
(PC/Mac/Unix/PDA) hardware base, or one that needs to make data
available to outside users (customers, suppliers, regulators, etc.)
on demand. The richness of Windows environment all of a sudden becomes
a luxury, unaffordable and unnecessary...

Hum, windows thin clients are available for all of the above platforms.
Again, it all depends are what we are trying to do here!

You are making an assumption that automation must be desktop-based.
This is not always the case, as I was trying to point out to the OP
earlier.

No, not at all!!! I am making the assumption that automation is a lot easier
to develop on the desktop (huge difference here!!). Further, .net is EXACTLY
the com object model extended to the internet anyway. So, sure, I agree that
automaton don't have to be desktop-based, but you need some inter-program
communication ability. And, the tools mentioned SUCK in terms of
accomplishing this goal So, no...I not making the assuming that automaton
must be desktop based, but I am certainly am point out that the tools
mentioned are VERY VERY poor in this regards. I explain why MS did not go
with thin client here:

http://www.attcanada.net/~kallal.msn/Articles/ThinClientsand.net.html

Great, no questions about it. Now let's say a customer wants
to see his account statement online. Oops; the desktop assumption
just proved inapplicable...

Sure, but who said the data resides on the desktop? ms-access is just a
client tool to connect to your favorite database of choice, be it Oracle, or
MySql, or sql-server. Why assume the data is on the desktop? Who said that?
You can come up with endless ideas here! The last 3 versions of ms-access
have shipped with a 100% compatible sql server engine anyway (this a true
client to server setup). So, it only lack of knowledge that assumes the data
is on the desktop here. Perhaps the web based part was written long ago.
Perhaps customers can lookup this stuff already on the web. We simply don't
know that..do we? Maybe we are building the report system for internal use
*after* the web system was built!! My point was that building the reports is
a zillion times easier with ms-access then the tools mentioned, and that
point stands. Fact is, the PHP and MySql don't have ANYTHING decent in terms
of writing reports. You will have to write REAMS AND REAMS of code. Again,
some type of reporting system needs to be used here to reduce the cost of
developing reports. If you are talking about web based, then lets use sql
server's reporting services.....a killer app in this regards. At least lets
admit that SOME type of reporting system should be used here in place of
coding everything!

You are probably right, but the customer will be able to see his account
statement online. You'll never be able to furnish data on demand to
remote or outside users, if you stick to the desktop paradigm...

Why can't a desktop connect and gets its data over the web? Who says that
the application has to be web based? There is soap, and even thin client
solutions that work on the desktop.

Further, I certainly MADE NO assumption that the data is on the users
desktop. If this debate is about the desktop vs the web, then leave PHP and
msy-access out of this. The fact is, the tools mentioned DO NOT have decient
data reporting ability. If we already made the assuming that PHP and Apache
are web based, then what much is there in the above statements? Gee, a non
web based system does not let people on the web view reports? To be really
honest, ms-access does have DAP's, (data access pages), and can be used from
a web server...but I not even willing to go there!! (and, the new DAP'S in
ms-access don't requite any client (office) tools to be loaded now). Fact
is, we still have to deal with the problem of EXPENSIVE developer time, and
how these reports are going to be built. The problem is not obvious issue of
web based vs non, the issue is how do you create reports in PHP and Apache?
So, all of a sudden you are debating about reports and who can see them? You
have not yet offered how those reports are going to be created? That is
putting the cart before the horse! How are those reports going to be created
with PHP and Apache? Surly you are not suggesting these tings will be hand
coded by a developer..are you? Look, ms-access has a great report writer,
and the above tools don't! Just what exactly is the person purporting to use
to replace the functionally of the report wrier here? I mean, if you need
reporting services on the web, then use sql servers reporting services...as
they are VERY GOOD! The problem is not that I can't find a really good
report writer for web based systems, the problem is that the tools
*MENTIONED* don't have decent report writing ability. And, as mentioned, how
do we know that the data is not already on a web server+ database anyway?

Not necessarily. The comparison definitely makes sense in terms of
what kind of situation dictates which approach...

Well, then start comparing those mentioned tools to the .net
environment...not ms-access? We don't need to compare PHP and ms-access to
figure out a different approach to deploying an application? Why compare
cars and clocks? At least lets compare a car to bicycles or something
similar!Sure, a debate about a rich desktop vs web based development is
fair, but it sure is not about PHP vs ms-access. As I mentioned, why not
choose c++ here? If this issue is about web vs non web based systems, then
we are CLEARLY off topic for this newsgroup.

Sure, and, since the report is saved as an RTF, the user can modify it
before sending it out

Again, why are you making the above silly assumptions? Who said to use RTF?
(again, a silly assumption on your part). Why not use xml (which ms-access
supports now), or just grab one of the MANY free PDF creators on the web. As
you mentioned, it is not always desirable to have the report or data you
send in a modifiable format...on the other hand, often it is.....especially
in a corporate environment where people need to manipulate and work with
data. Often, the data goes to Excel for example. This is moot point again.

How would you
like to invest your money with an adviser who can manually modify your
account statements? The question, unfortunately, is not hypothetical;

No, it is not hypothetical, but this discussion has sure defected to
grasping at straws. Are you telling me some format like PDF, or other forms
is going to solve the above mentioned problem? What is stopping the
fraudster from typing up a letter and faxing it to me? How ON EARTH do you
know exactly how these people commit the fraud, and what does that got to do
with ms-access, and PHP? You mean now we are in a debate about fraudulent
behavior? Are you telling me that PHP prevents this kind of fraud? Are you
telling me that using PHP would have prevented the above fraud? If the
person types fraudulent numbers into the accounting system, then a web
based, or using ms-access to reports on this fraud data makes NO difference.
I have no idea what you are implying with the above statements about
corporate fraud?

If you are telling me that fraudulent people can modify data, and that it
might be a good idea to not use a document that can be modified by someone,
then fine (as I mentioned, this solves little in the way of fraud). How on
earth does this relate PHP vs ms-access?

ok...this thread is tanking badly......time to stop here!