daltman1967;10991944 wrote:
Yes, I am selecting ALL the records in the particular set. However, ALL of these are "the records I want."
No, right after selecting all records and looping over the entire result set to store them all, you discard them all in favor of one single record, which you don't even retain from the allready selected records, but for which you issue a separate query. Well, you don't really discard them, you just never user that data for anything but retrieving the the P'th id from the result set, which you really would be better off doing using SQL instead.
daltman1967;10991944 wrote:
Until the user selects the exact record to edit, there's no way of knowing WHICH record to go to.
Except that you've somewhere stated that until the user selects a specific record, you show them the first record, which means selecting only one single record the first time. As far as I've understood you, from that point on, you provide them with previous and/or next links, which means that you will always know which record to retrieve. The same still holds if you let them specify that they want to go to page 200 directly, rather than clicking next repeatedly.
daltman1967;10991944 wrote:
I'm not checking to see if a specific record exists.
Well you're literally not doing that. You are however assuming it does.
if(isset($_GET['p']))
{
# fine, due to the above check, you know that $_GET['p'] exists
$p=$_GET['p'];
# You then assume that $id[$p] exists. You ought to check that it really does.
# Either way, this is where you do what I meant by "checking if record exists".
$ix=$id[$p];
}
# But whatever the case, you then select the exact same data from the db again
# using this SQL query
$query = "SELECT * FROM my_table WHERE ID='$ix'";
Do note that when I say "exact same data", I refer to the data you originally retrieved from which you then stored only the id. This is also a waste of resources, since you can tell the DBMS exactly which columns you want to retrieve. It's considered good practice to always specify that, even if you actually need the entire set of columns.
daltman1967;10991944 wrote:
All the records in the set are being chosen. Then, out of 'n' records, the user is choosing one (or two, or seven) to edit - or, perhaps, add a new record. Perhaps they're just looking at the record to read what's there.
No, the user have allready selected a record (or you have said it should default to the first record), which means that you have ONE SINGLE record on which to operate. Retrieve that ONE record and do whatever you want with it. Do NOT retrieve all records first, and then DIRECTLY after that retrieve the one you want.
What you are doing here is equivalent to deciding that you want to talk to the youngest member in a family. You then ask them all to leave their house and tell you their ages. They are 5, 14, 40 and 44. Then they go back inside the house. Finally you tell them to send out the five-year-old.
Do note that it's entirely possible to tell them to send out the youngest person straight away. Or the second youngest. The family knows who that will be even though you have no idea of their ages until you have the person in front of you. But telling them to send out one person is enough.
daltman1967;10991944 wrote:
The bottom line is, the whole purpose of this is to EXACTLY duplicate the function of my MS Access database. I'm now well on my way.
There is no reason to do it this way in MS Access either, although it is entirely possible. But I suspect you are trying to mimic behaviour in MS Access which you can get without writing your own code to handle the pagination.
daltman1967;10991944 wrote:
I don't see how it will be 'inefficient.'
Let N be the number of records in your table. When comparing your approach
First SELECTING N records,
then performing N iterations to retrieve that data from the result set resource
then SELECTING 1 record (the one you need)
then retrieving that data from the result set resource
to
SELECTING 1 record (the one you need)
it is obvious that you are first telling the db to return N more rows than you need (N + 1) - 1, and then perform N more iterations than you need N - 0. Thus, your approach is inefficient.
daltman1967;10991944 wrote:
Even with thousands of records, the first while only takes a fraction of a second to run. There's also a finite number of records for each year, which makes the subset of the whole even smaller.
I'm not saying it's impossible to use your approach if you have less than a certain amount of rows and one single user. I'm saying that your approach will not scale since it is inefficient. And I believe it's a good idea to get such advice as this should you ever need more concurrent users or have so much data that it takes too long. Also note that you do not specify that you only want records from this year when first selecting all records. There is no where clause at all.
daltman1967;10991944 wrote:
As far as I can tell, this was the ONLY way to get what I wanted:
And I've been trying to tell you it is not. But I am not telling you that you HAVE to do it in a specific way. If you want to stick with yours, by all means, don't let me hold you back.
I was merely trying to give you some advice which I personally believe to be very good advice. I was also hoping to help you avoid headache down the road. I also believe you came to this board because you wanted to learn.