- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Of course, I might not. But with pagination there is often no way to express that I want all results at once. Also, pagination does not solve the issue you raise: with pages there a still a lot of hotels in New York except now I can't do CTRL+F "Daily Rate" (or whatever search criteria the developer didn't deem necessary to include). A better design would be to have a message "hey, sure are a lot results .. you can refine your search like this etc"
That's easy hand waving! In this example the reason is that the user store actually is a composition of an in-build user database (but with a horrible object/binary schema that you wouldn't be able to query) and an LDAP and an other LDAP neither of which I had access to.
Yeah, not the tools for the job but considering that pagination does not solve any UI problems (but rather, and that's the only appropriate use for it, performance problems) and at the same time breaks the age old "copy 'n' paste" interface I think it's never a good idea to include pagination "just because there could be many entries".
Never break Copy and Paste!
Admin
Those of us with true hotel-fu make our choice based upon the price (and other sundry conveniences and attractions) of the bar down the road. Once upon a time, in the early days of the 'net, we could look forward to the day when an online reservations system might actually give us this choice. Now, it's all corporate bullshit, and whether or not you should separate DB from BizzTalk from PHP (clue: PHP is in the cage, over there), and which friggin Mercator projections to use.
What you fail to realise is that programmers are perfectly sensible people, yet we are raised to a level akin to Boddhisatva.
We argue about all this crap precisely because we don't want to "get invited to meetings."
Admin
This user doesn't givadam. I want a general idea of distance...I want to know if the hotel is 1 mi or 10 mi from $touristsite...don't care if it's 1.1 or 9.9.
mr
Admin
mr
Admin
Shhh! Don't spoil it for the rest of us
Admin
Same here. I'm not convinced that retrieving ALL the results to paginate is a good idea. I also like how the pseudo-code has a hard-coded "10" as well as an "itemsPerPage" variable. But well, it's only pseudo-code, maybe the implementation is actually smarter.
Admin
Yeah, I agree it tends to be annoying. I like the sites that give you the option. Other sites provide a print article function that puts everything on one page for you.
Otherwise, I expect decent sorting options to allow me to "filter" so to speak what comes up at the first page or two.
bc
Admin
Mod +1 QOTD
Admin
The hotel location changes in real time?
Yeah, thats my kind of hotel! (Or maybe its the brandy)
Admin
Exactly, in large enterprise systems it's not uncommon to have a couple of tiers. The DB is typically at the lowest tier, with some data access tier just above that. Depending on the size of the system, there might a services (business rules) tier just above that and next to that there is view tier. All of these tiers run server side. Perhaps on the same server, but most likely at least the DB is a different server and the other 3 ones run on an application server (e.g. Java EE, .NET, etc). Finally, there's the display tier that consists of the HTML, scripts, etc that run in a user's browser.
It goes without saying that the kind of logic the article mentions should not be done in either the user's display tier or the server's view tier. It's most likely best at place at the services tier.
In general, there is a tension between doing stuff in the DB and doing stuff in the AS. The DB might be a central thing, while you might have several application servers. In terms of load distribution, it might make sense to offload some processing (like sorting) to your AS, even if the DB could theoretically do this. Caching solution like Oracle Coherence often take such an approach. Another rationale is that you might have global business rules in place that are not easily expressed in terms of SQL or where such rules apply to data from many different sources (webservices, files, perhaps user input) and you don't want to duplicate their definition for each source.
Remember that not all applications are of the pattern {"query db", "iterate over result-set and spit out html"}
Admin
Amen to that!
I've seen quite a lot of systems being build where the engineers thought the DB was basically everything and that anything and everything should be done in SQL. For those people, JSP, PHP, etc are just needed to wrap a little HTML around stuff that's returned from the DB.
For some reason, those systems always seem to fall apart when the system grows in complexity. Now I wonder why that is...
Admin
Here, in a nutshell, is what's wrong with Java development.
Admin
In ASP.Net? I'd use this little thing called a POSTBACK to store the session id. Cookies are the realm of long term storage/multitab records, or of course (in your case) old school thinking.
Admin
And yes, I know about sharing of the link between friends and those various arguements against POSTBACK. But for the problem you stated it is a valid solution, and your suggestion of using cookies would have had the same problems.
Admin
That was a sad ending! I was expecting some inspiring message. I was thinking maybe Greg had taken that long because he had made the pagination system himself from scratch but Bruno didn't realize it and Greg got it working. The end.
Admin
Silly me. I forgot to mention to use common sense. My bad.
If the hotel search gave you millions of results, the WTF is quite different from a pagination-related issue, I suppose.
Admin
I think that the REAL WTF is that so many people here don't understand the difference between good, and good enough...
Admin
Suggestion: get a refund for your Comp Sci "education". You were ripped off.
Admin
Define a store procedure that execs the query into a cursor and then culls them according to a "driving distance" parameter...
... having said that, a database might need to interface with an external system to do that type of geographical computation. For instance, Oracle can run Java or contact a LDAP server, but I don't know about other databases.
The thing is, to compute driving distance from point A, you use a standard location field for each record point (.ie. a zip code for instance), each standard location field having an estimated area size. That zip code is distance zero; select those zip codes adjacent to it (these are distance 1), select those zip codes that are adjacent to those at distance 1 and label them distance 2, and so on until you reach the first estimation with an estimated area larger than the driving distance. That's your area of interest.
Then, you return those hotels that are in that area. The calculation for "area of interest" could be performed inside the database (as part of a stored procedure), if the DB has access to such spatial info.
Otherwise, the middle tier (not front-end or back-end or whatever PHP/JSP/xyz developers want to call it), middle tier can do that calculation, and pass to the db (again, via a store proc) an array of zip codes of interest, with the result being the same: get only those hotels that are in the zip codes of interest.
If sort by 'driving distance calculation' could also be done in the db, that'd be great. However, if that's not the case, the middle tier can do so w/o having to ZOMG!!11 SQL * FROM HOTELS!!
Admin
[quote user="Luis Espinal"] For whatever reason, they had to cull out unavailable hotels after they retrieved a list from the DB. Also, hotels needed to be sorted by distance which could not be a part of the SQL query, so getting 10 results at a time would not work. The system needed ALL the results so it could process the list and THEN paginate.[/quote]
Define a store procedure that execs the query into a cursor and then culls them according to a "driving distance" parameter...
... having said that, a database might need to interface with an external system to do that type of geographical computation. For instance, Oracle can run Java or contact a LDAP server, but I don't know about other databases.
The thing is, to compute driving distance from point A, you use a standard location field for each record point (.ie. a zip code for instance), each standard location field having an estimated area size. That zip code is distance zero; select those zip codes adjacent to it (these are distance 1), select those zip codes that are adjacent to those at distance 1 and label them distance 2, and so on until you reach the first estimation with an estimated area larger than the driving distance. That's your area of interest.
Then, you return those hotels that are in that area. The calculation for "area of interest" could be performed inside the database (as part of a stored procedure), if the DB has access to such spatial info.
Otherwise, the middle tier (not front-end or back-end or whatever PHP/JSP/xyz developers want to call it), middle tier can do that calculation, and pass to the db (again, via a store proc) an array of zip codes of interest, with the result being the same: get only those hotels that are in the zip codes of interest.
If sort by 'driving distance calculation' could also be done in the db, that'd be great. However, if that's not the case, the middle tier can do so w/o having to ZOMG!!11 SQL * FROM HOTELS!![/quote]
Quoting myself to present a caveat: Doing the adjacent zip calculation is a cheap way of doing things, and it would require to have estimated dimensions for each zip code.
There are tools and services out there for that kind of thing, and if a company provides that kind of web search capability, I would imagine they can afford to rent/buy that kind of computational service to meet their business needs.
Admin
Fast algorithms for these kind of things require preprocessing that commercial databases don't provide.
captcha: vereor -- Truly eeyore?
Admin
The basic problem is that the kid does not have the algorithm correct, so his code does not work, and he tries to fix the code. I used to do this in my early days. Finally I began to build a list of algorithms which were independent of the implementation code. I think my first was how to read a sequential file and give multi-level subtotals. Not easy in FORTRAN.
Now, of course, I've learned to work out the algorithm first, then implement it.
Admin
You'd run out of memory and/or bandwidth limit first I'm afraid.
On a more sensible line of conversation, the last thing I want is for the web application to dump one thousand results to me and have to wait for it to render, then after I do something within one result I have to wait for the whole freaking thing all over again and so on. What the man describes would only ever be useful in lists you can new-tab off of.
Admin
You do realize that these 3 can differ a lot from eachother? Hell, just changing the direction can alter the result a lot. office parking lot -> nearest Burger King (car): 2.0km nearest Burger King -> office parking lot (car): 2.8km office parking lot <-> nearest Burger King (walk): 900m
IOW: You* have to decide on ONE of them, in which case the faster-to-calculate "as the crow flies" becomes viable again.
Using eg Haversine formula will give a good enough result. If anyone cares about a specific way to travel between A and B they will look at a map anyhow. Using street maps etc on the inital search is certainly overkill. Actually, Haversine already is a bit too much for almost anything < 20 km. If you really want to, let the user pick favorites from the search results and then offer a "distance analysis" using all the different graphs etc. I dare say on most sites that feature will have less PI than your "about us" page.
*: Of course you can leave the choice to the user, but most people will not care anyhow. Or lack the knowledge to make an informed decision.
Admin
Exactly, I was surprised that this wasn't in the earlier comments...