| |
| |
| |
|
Page: 1 2 3 4 5 6
Comments:
<0> Oh yeah. ACID, compeltely a waste.
<1> and transactions have nothing to do with overhead
<0> I stop now. You're obviouslly without clie.
<0> clue*
<2> ah so you concede?
<3> DrToast: THIS is why mysql isnt answered
<3> cause a lot of people who use mysql are idiots
<1> note that the cardinal rule supercedes 'Fast' or 'moron proof to use'
<4> trolling is best done in #teen***
<2> ok so I have a table that is being used 90% of the time and its going really slow
<2> your solution is just to tell people that its tough luck?
<3> DrToast: how are you guessing at our solution?
<3> ill tell you one thing though.. the solution is not to take away transactions
<5> how many rows, is it indexed, more detail, blah blah blah
<0> Concede? No. I just choose not to stoop to your level since you're obviouslly clueless about database reliability and design.
<2> well you are resorting to ad hominem attacks
<3> Drk`Angel: you obviously are still stuck in that oldschool mentality that transactions are needed
<2> that indicates that you are either immature or you're dodging the question
<5> you didn't wrap your trouting in a transaction for possible rolling back of the trout. ****ing hypocrite
<0> Anyone who ever says "sometimes transactions are not needed" is missing some fundamental details about how and why databases are used. Once you can figure out the basics, we can have a discussion. I am, however, not here to educate you.
<5> i think you mean 'edumacate'
<6> sometimes they arent needed. most times they are. now shut the hell up since all 4 of you are stupid
<2> you are missing fundamentals about the real world where there is a delicate balnce between performance and elegance
<5> sounds like a condom ad
<2> yeah in a university cl***room its easy to say that YOU MUST ALWAYS USE TRANSACTIONS
<3> DrToast: ok so you are saying that sometimes they are not needed but sometimes tehy are... but mysql didnt have them at all
<3> what do you do when they ARE needed?
<1> it's pretty ****ing simple.. if you need to execute a set of operations that are mutually dependent on the success of each operation, you need transactions
<2> mysql has them now
<3> no u were making a point saying that mysql was ok when it dindt have transactions
<2> and it has the ability to have them on some tab;es and not on others
<3> saying that sometimes they are not needed
<1> if you are _never_ doing things that require that, you probably don't need an RDBMS in the first place
<6> 'mysql' doesnt have them. 3rd party includes have the ability to use them while running mysql.
<2> well it seemed to work out of the box for me
<2> anyways the point is to use transactions everywhere except in situations where you need performance
<3> thoguht u didnt use transactions
<6> where does it say that transactions will reduce performance over and identical set of non transaction enabled DML?
<2> I use transactions on all tables except the one that 90% of the select queries are done on
<1> i get the impression that you don't fully understand what transactions are
<6> you must be a crappy dba
<2> well maybe you should look at some benchmarks
<3> transactions is like after *** she demands money and you have to give the money to her
<2> ad hominem ad hominem
<6> many times transactions are better performance
<2> no true scotsman puts sugar in his porridge
<6> condensed commit time and logging
<0> I've never had any problems making my applications more than fast enough using databases which are transactional. guess the art of query optimization is dead.
<3> Drk`Angel: query what?
<0> Might as well just rip out the failsafes and pray instead.
<6> because the scotsman is too poor to buy sugar. he just wishes he was an irish
<1> rarely is 'fast' a problem that can be directly attributed to whether your database implements a transaction model or not
<2> just as the art of rational debate is dead
<0> DrToast: Its hard to have a rational discussion with someone who is irrationally attributing performance problems to the wrong thing.
<2> its hard to have an argument with a religious zealot too
<7> Saying that keeping something ACID never causes any performance hits is not really being rational, though
<1> DrToast: when you were developing your applications and decided that a commercial product or postgres weren't 'fast' enough for your requirements, how did you determine this?
<6> just because im a religious zealot, doesnt mean you are any less stupid
<5> just wrong
<2> evolution is evil! mysql is evil!
<1> evolution?
<1> hahah
<0> flupps: Still, database tables with millions of rows, working though a couple of hundred transactions a second. I have a hard time seeing how removing transactions will make anything appreciably faster.
<2> have you ever ran any tests on it
<2> or are you going on faith alone?
<1> DrToast: if mysql is the 'evolution' of database design, why are they continually going back on their original design goals and implementing basic RDBMS features that they originally stated as unnecessary?
<0> No, because 1) it doesn't need to be faster and 2) its financal data. removing transactions has a high probablility of corrupting the data.
<0> ACID exists for a reason.
<2> naw i'm just comparing you to the Intelligent Desing crowd
<8> Without integrity speed is irrelevant.
<1> DrToast: what types of data do your databases hold?
<1> ie: what applications are they backing?
<8> The first and foremost purpose of a database is data integrity.
<7> Drk`Angel: in that case, shouldn't matter, sure.
<0> And, its downright AMAZING how fast a well designed database can be.
<0> Even while staying fully ACID compliant.
<8> If you want faster, write to a proprietary binary file format.
<8> You'll outperform MySQL easily.
<8> But I sure as **** won't trust my data to it.
<7> unless you create that binary format as a storage engine ;)
<0> I think the biggest problem of the mysql crowd is they drop a defauly install mysql db onto a desktop p5 with one disk in it, and find that its faster if they turn off transactions.
<0> Instead of actually tuning the db install and data design to the point that it fast and safe.
<0> Weird, I know.
<7> the problem why many see it that way for MySQL is because InnoDB has some flaws
<2> gripe: just some simple websites
<2> see oracle or db2 or whatever is kinda overkill for that
<8> "kinda overkill"
<1> it's likely that mysql is as well
<8> Fine, pgres.
<8> ****, DB4
<0> or, use the free edition of oracle.
<8> DB4 will be faster than MySQL on a webserver.
<2> what does pgres offer tha mysql doesn't?
<0> Or mssql express.
<2> does mssql run on linux now?
<1> DrToast: data integrity
<8> Any half-decent embedded/file-based DB would be faster in such an environment.
<1> plus a plethora of other features mysql is attempting to bolt onto their database after realizing leaving them out was a mistake
<2> well see one of the fields is the location of an uploaded image
<8> heh
<2> if the image is deleted, I lose integrity, right?
<8> so?
<2> so I have to be careful in the script to make sure that doesn't happen
<8> If you want to use MySQL, use the channel dedicated to the product.
<0> gripe: That would be mysql biggest problem. Running around finally adding on needed features after yelling for years about how un-needed they were and how they were full featured, even without them.
<2> so if i have to be careful anyway... well
<8> It's one thing to verify and validate the existence of data stored outside of the DB. It's a different thing entirely if the DB cannot even verify and validate the **** you put into it.
<7> Halo_Four: how doesn't it verify ?
<8> If a database accepts and permits February 31st, it is, by definition, a steaming pile of ****.
<8> Check it in Websters if you don't believe me.
<1> oh yeah, i forgot about the date ridiculousness
<2> even as a string?
<7> eeyore> INSERT INTO t1 VALUES ('2005-02-31');
<7> ERROR 1292 (22007): Incorrect date value: '2005-02-31' for column 'a' at row 1
<1> good idea, store a date as a string
<8> If you're storing a date as a string then you should be shot in the head.
<2> lol
<8> flupps: Congrats for running 5.1 in strict mode.
<0> DrToast: interesting arguement progression from "transactions are slow" to "well, I have to validate data outside the db anyways, so I might as well not worry about possible data inconsistancy anyways"
<3> lol
<2> what?
<7> Halo_Four: 5.0 default installation.
<8> How about 0000-00-00?
<2> Ok so how do you maintain data integrity between the database and the uploaded image files?
<5> jesus' birthday
<7> ERROR 1292 (22007): Incorrect date value: '0000-00-00' for column 'a' at row 1
<5> DrToast, you do it yourself
<8> How about BEGIN TRANSACTION; BEGIN TRANSACTION; DELETE FROM t1; COMMIT TRANSACTION; ROLLBACK TRANSACTION;
<5> in the application logic, not in the db
<2> the answer is that you have to make sure your script is good
<1> DrToast: how does this question tie into your argument that mysql is a better choice than something else?
<2> but oh noes! there is no transactions for that!!!!
<5> no, there isn't. its called error handling.
<9> woh.. nice big channel
<3> someone boot his ***
<3> :)
<1> DrToast: you, sadly, don't have a CLUE what you're talking about.
<7> Halo_Four: have to use savpoints on MySQL to get that behaviour
<2> what am I ever to do, because the solution to every problem is transactions
<2> no, I'm just looking at the big picture
<1> DrToast: learn what transactions are, what they're for, and why you' use them.
<8> Dr: Just please wear a special hat at all times so that I can easily weed you out in the interview process.
<2> you're being small minded
<8> The big picture is that you're a stupid ****.
<8> That's pretty much it.
<2> I wouldn
<5> i just realized that i've been cupping my crotch throughout this entire conversation anticipating the next salient argument, and i'm actually in a lot of pain now
<9> wtf?
Return to
#sql
or
Go to some related
logs:
SQL LIKE CASE IN
#mirc
#unix
#sex
#computers
#tcl
#flash
#gamedev
#flash
e17 transparancy
|
|