worst DB program ever


just thought I'd share that

carry on

EVER

mySQL

YOU WILL SUCKLE AT BILL GATES' TEAT AND YOU WILL LIKE IT!

Who still uses it? I last used that in 2003 in the government...even the govt ditched it.

it's almost as bad as openoffice base.

what else is user friendly?

Microsoft Access has its uses. I don't use it myself, but since I work at Microsoft there are alot of people that do use it.

Even I switched to mySQL, even though I was an access fanboy.

I concur: mySQL is the worst DB engine ever!

What are you trying to do with Access though? It's perfect and powerful tool for managing even largeish amount of data, for a couple users. Easy to code, easy to maintain. If you try to use it for anything bigger it's your worst nightmare. But not Access problem; it's the project manager who chose the wrong tool for the job.

In contrast, mySQL is bad from every point of view; except the "price". If you want something powerful get SQLServer instead. (Yeah, I know, it's not free, but the Express is).

I think you can delete the word "access" from the title here. (someone had to say it)

-Fooglmog
Guy with no clue.

I know my Mom's company, Coca-Cola Botteling Company Consolidated, the largest independent botteler in the United States, still uses it. She fluffes about it all the time.

"What are you trying to do with Access though? It's perfect and powerful tool for managing even largeish amount of data, for a couple users."
I disagree.
by financial institution standards, "medium" amounts of data would be in the 500K + records over 20 fields.
"large" would be in the 5million+range with 70-80 fields at least.

If you are trying to do VERY simple database queries then it's ok.
But even something like: "recode this numbered field into ranges of categories" is very painful in access if you have 10 categories.
If I want to group data by 10,000 categories (SQL group by) access dies for example.

The mini dataset I was using had about 300K records with about 15 fields (mostly text).

I find Access interface wise to be very cumbersome and annoying tbh.

Then again I have been somewhat spoiled by SAS and APL.


Just ignore my rant:P

DB2 ftw!! *runs*

5 million records is tiny!~

our news lookup table is 12M records alone !! :)

mysql ftw... we're just getting started here too really, 3GB in 50 tables, most of which is attacking news and country news....

*shrugs* I just did a few quick tests. I don't have an access db with a table with 500k records but I joined 4 tables for about 400k records total. Simple "select all from inner join blah blah" took 1 second. Group by every field (about 60 or so) took 28 seconds, not really funny indeed. Group by primary key in each table, 3 seconds. Group by 16 indexed fields (all text) took 5 seconds. Each query returned actually the same number of records, those 400k. When limiting the size of the recordset with a "where" clause it was much faster (except "where text_field like *something"; that one took much longer than "like something*" but still about half of the time of the group by without the where). Not the fastest ever but certainly workable.

I am with the MYSQL group. Used it many times however I don't like Access' interface, I really do prefer CLI. Then again, i didn't play with Access a lot.

MySQL vs SQLServer... now I don't know which one is better, both seemed good from what I used and needed it for. (Tables were gigantic since they were storing financial stock data and all the audits needed) Craptastic thing was that we had to use both, so I mixed syntaxes sometimes for the temp tables for future joins.

I do like SQLServer's profiler though. Fun to learn about SQLServer more indepth than most people would want to know.

JOINS ARE SLOW! DIE JOINS DIE! ;)

handling the equivalent of joins in the code and doing simpler queries is usually faster

Yeah well, it seemed the easiest and quickest way to get a hold of a 400k records and toy around with it without wasting more than 5 minutes. And obviously no sane person would do a group by 50 columns in 4 tables query especially knowing beforehand that the records were unique and there's no point grouping anyway :p

MySQL vs SQLServer. I did test that once; a web application, same tables, same data in tables, same queries, same machine; db engines were SQL Server 2000 and whatever mySQL was declared "stable" that morning, I forgot (was a while back). SQL server won hands down, performance-wise. (edit: could be because the mysql odbc drivers were crap though, I haven't been curious enough to play with MySql in a Linux environment)

qz: it's not just the number of records but the number of fields in each record.
5 million records isn't so tiny when the size of the db is 200 gigs... (ie they have a *lot* of fields and you need most of them in many cases)
:P

how about you learn how to normalize and grasp an understanding of what a relationalship db is made for.

might even want to index it correctly instead of treating it like a holy glorified mother of god excel spreadsheet.

because i know that's where you're coming from...

because I'm Dibs.

your tables are too complicated then! lol ;)

vertical partitioning!


though if they're just massive tables and you don't need to search on anything other than the primary key, you should have no problem; build lookup tables for anything more complicated than that...

i wouldn't even call MS Access a db ;)

Microsoft doesn't call MS Access a db either. It's only the graphic interface for the jet db-engine... ;)

LOL, DAO has been deprecated. what jet? they use ADO now. :P

No Jet. meh, it beats trying to use MySQL with ODBC. i'm sorry, did you actually want me to do something with that join, or should i just show everything as deleted because i didn't understand anything about ANSI-SQL...

http://www.mongodb.org/

dibs is out in full force:P

it's not an issue of indexing. Certainly one could make multiple lookup tables and re categorize that way.

Access still sucks:P Try doing calculated fields with it for example:P

Also qz: that is a lot of programming/procedural acrobatics needed to accomplish something :P
In any case I used something called APL instead which was a lot faster.

NoSQL anyone? might be helpful for you.

Hmms.. I thought there was something called Zero sql or something like that, but I can't seem to google that anymore.

you mean you want to show a calculated field on a form and still be able to save the record? just wrap it in a vba function.

I used Access in college for my access class and it was fine enough for me to get an A in that class.