| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9 10 11
Comments:
<0> Jivedue, I am not a novice programmer, I have written C programs (GPL) with more that 5k lines of code. I am just a novice in web programming/SQL
<1> eleftherios, when you are rendering the table, make the column headers links like that, with the right sort= and maybe a toggle for ASC vs. DESC
<2> eleftherios: then split on the pipe-char and tack on: ORDER BY $split_result[0] $split_result[1];
<1> eleftherios, simply fobnosticate your discombobulator and run the output through a mystifier
<0> haha
<1> you can pick up a mystifier at any plumbing shop
<2> ericP: where do you put it?
<1> Jivedue, i hesitate to say...
<2> ericP: I guess you'd need physical access to your server, which I don't have
<1> Jivedue, so you hope. maybe i've cracked your machine just so i could store my critical data there
<1> Jivedue, please go easy on the credit card or my wife's gonna kill me
<2> ericP: my discombobulator is corrupt :(
<1> Jivedue, perhaps we can start a dada-ist help desk
<0> hm, could you please tell me again how do I set ascending or descending order in SQL?
<2> add "ORDER BY <column_name> [ASC | DESC]" to the end
<1> ORDER BY user DESC
<0> oh, nice
<0> thank you, I didn't realise it was that simple
<0> :-)
<0> hm, I think I have a design flaw in my cl***. I started coding it having in mind that the caller of the cl*** will handle the DB connection...But now if I want to change these things (descending/ascending order and ORDER BY) then my cl*** needs to handle the DB connection in order to call SQL statements...What do you think?
<0> or at least, the caller of the cl*** needs to understand the conventions that the cl*** uses for setting the functionality for these features (setting the order etc.)
<0> or I am very confused.
<3> conventionally, you will have one cl*** for accessing one "thing" in the database.
<3> that cl*** will know (but not necessarily manage) the sql connection, and it will construct and execute the query
<3> if that cl*** does not know by itself in what order the results should be, make an option for that, and have it construct the query accordingly
<4> hey, is it possible to add constants to the select list in an sql querry?
<0> Duesentrieb, true. But the cl*** I am constructing is meant to display a record set as an HTML table (with some bells and whistles)
<4> so add an extra field with a constant value?
<0> Duesentrieb, it does not execute queries
<0> Duesentrieb, perhaps that's the flaw in my design :-(
<3> Cereal: select *, 23 as foo from...
<4> and a string?
<4> select *, 'user' as type from
<3> eleftherios: indeed :)
<3> Cereal: sure
<5> hey i'm new to mysql, can anyone explain to me why this query doesn't work? "SELECT COUNT(*) FROM table WHERE GROUP='computers';"
<3> because GROUP is a reserved word
<3> is it actually the name of a field in table?
<5> yeah
<3> (calling a table "table" isn't very smart...)
<5> its not called table#
<5> i just changed it befor ei pasted
<5> to make easier to read
<3> then use backticks to quote it: `GROUP` = 'computer'
<0> Duesentrieb, pagination will be another problem too (as I don't have a clue how to create it)
<5> thanks
<3> eleftherios: LIMIT offset, limit;
<6> is there anyway to UNDO a change I have done to a table?
<3> after you comitted, no.
<3> (per default, when the query is through, no)
<7> restore from a backup and replay the log
<0> Duesentrieb, unless if I make the cl*** SQL agnostic and it just sets some flags on each header it calls. Then the cl*** that handles the connections parses these flags, creates the relevant SQL statement, and hands the result set back to the HTML displaying cl***. The benefit of that is I seperate the connection management from the HTML output. What's your views?
<6> Darien: ok. thanks...
<7> a guy at a friend's work engineered a system whereby for every SQL transaction, not only did it perform the transaction, it also recorded the transaction itself, as well as the transaction required to undo it
<7> making it possible to make retroactive changes in the database by undoing everything back to a certain point, performing a different query, and then replaying everything forward again
<7> so you could retroactively change someone's monthly fee (for example) and their balance sheet would update accordingly
<3> eleftherios: that would be the next step of atraction. As long as you don't have to p*** around entire result sets, but only a few hundred entries, it's ok
<3> problems generally start when you need to p*** back a database cursor, because buffering the data in your aopp would be too expensive
<3> Darien: neat
<7> yeh
<0> Duesentrieb, I lost you...(sorry I am a novice in web/SQL programming). How can I avoid p***ing back the result set for such an operation?
<0> Duesentrieb, are you by any chance familiar with PHP, can I explain things in terms of SQL/PHP?
<8> you can try
<3> yes
<0> thanks
<3> if you put the data into an array to retrun it, the caller does not need to know about the database
<3> works fine, as long as the array doies not get huge
<3> if it could get use, the caller needs to access the cursor directly
<0> Duesentrieb, this will be for big tables potentially :-(
<3> (or a wrapper object)
<8> it's still going to be a performance hit
<0> so I have to think for the most efficient way
<8> and a memory hit
<3> eleftherios: if you do pagination, you will never have that many rows in the result anyway, right?
<0> Duesentrieb, yes but I am confused.
<0> Duesentrieb, I am making a cl*** that will display a result set because I don't know how to deal with matters of efficiency yet. But now I bumbed on these problems and I am a bit lost.
<0> Duesentrieb, If I do pagination and the result set is 1000 rows I will only have to deal with 10 a time
<0> Duesentrieb, but that means that my cl*** must manage the connection too
<3> if you let the db do the pagination, yes
<0> :-(
<3> you want two cl***es, right? one for db access, one for rendering
<0> yes that would be best I thought
<0> because it seems messy otherwise
<3> the one for db access needs to know the sort order, the "page" you want, and maybe some other things
<3> it will run the query, and return an array
<0> the result set
<0> yes
<3> well, depends on what you mean by "result set".
<3> it's a fixed expression with regards to the db, and the array contains results, but it's not "The Result Set".
<0> in PHP I use the ADOdb for PHP abstraction layer on top of MySQL, it returns an object which is basically an array plus some more goodies
<3> it gives you all data back at once, as an array?
<3> or one arry per row?
<0> all at once
<0> I handle taht to the cl*** (it is called DisplayTable)
<3> ugh. that's ugly. but if you use the appropriate LIMIT, it should not be too bad
<0> you think it is ugnly huh? Is there a 'proper' way to do it?
<0> s/ugnly/ugly
<3> generally, using the db cursor. I have never used ADO, but they probably support it. But if you want an array anywqay, and can limit the size in advance, don't worry about it.
<0> I have to read about db cursors because I am not aware of what they are and how I may use them
<0> how would it be done using the db cursor? And why is it better?
<3> the cursor is like a file pointer
<0> I see
<3> you run a query and get back the cursor (a unique resource)
<3> you can then fetch rows from it, one after the other
<3> the result is a stream of rows, without the need to ever store everything in an array or some such.
<3> very useful for large sets of data
<0> oh I see
<3> advanced cursors can also go backwards or even insert/delete/update rows. but that's... advanced ;)
<0> well, I will have to handle large sets of data for sure
<3> not if you use pagination
<3> or am i getting you wrong?
<0> no I will use pagination too, it is a requirement
<3> this would only be relevant if you want to show more than 1000 rows on a singe HTML page
<3> so, simply put a limit on the query
<3> that way, your array stay small
<3> no problem
<8> copying all that data just to read through it again makes no sense
<0> so I can either use pagination (given that I limit the queries) or cursor
<8> you're going to increase your memory footprint a lot
<8> I realize most of the time memory isn't an issue with php but it's still something to consider if you plan to scale your site
<0> firewire, this will be used for an accounting application that will run over the web and it will definitely scale to *huge* amounts of data :-/
<3> if he only uses 10 rows at a time, i wouldn't bother
<0> well, I can set a limit to 100 rows per page, that's sensible
<3> eleftherios: the question is not how much data is in the db. the question is how much of it you have to handle at once to construct a singe html page
<8> eleftherios then you probably don't want to add the performance hit of copying that data twice and having it in memory twice
<3> hehe
<0> I can set a drop down menu with 10,50,100,200,500 or something
<8> eleftherios is the issue here that you don't want to make mysql_fetch_* calls everywher in your code?
<3> firewire: he wants the rendering cl*** to be oblivious to the db.
<8> use pear db
<3> can be done be wrapping the result set in an object
<3> but hey...
<3> firewire: that still means it has to know the queries.
<0> firewire, I have to use AdoDB for PHP, it is not my call what library to use :-(
<8> adodb is fine just dno't use it's caching
<0> ok, I am very lost now...
<8> eleftherios the display layer can know about adodb without knowing about queries right?
<0> the display layer can know that it is being handed an AdoDB result object if that's what you are asking
<8> ok so what's the issue?
<0> firewire, is that what you are asking?
<8> make the db call then hand your display layer a adodb object..
<0> firewire, hm, I am not sure anymore, I need to reconstruct my
<0> thoughts
<0> firewire, yes this is what I am doing
<8> ok :)
<8> that was easy
<0> hmm
<3> you should find out if the "ado result object" is basically a cursor, or if it stores everything at once.
<8> good point
<8> hmm if I recall it stores everything at once
Return to
#mysql
or
Go to some related
logs:
random characters in php
15 0 * * * /usr/bin/perl
#perl
what is accessing my cdrom drive
php script with a csinfo command
truecrypte debian
#physics
gentoo coldplug and udev conflict
gentoo blender segmentation fault
#perl
|
|