Checkboxes for Add To List

[Thatguy2001au]

Hi guys

Already you guys have helped me a great deal so i thought you'd probably have an idea for what I need now.

I'm working on a site where users are able to able to advertise a product for sale. All records are sored in a sql server database. When a visitor wants to see what's for sale, depending on their search query, anywhere up to 20 records can be viewed on the one page which are all of course retrieved from the database.

What i want to do, is have an option where there is a checkbox next to each advertisement on the page and by Clicking on the checkbox, it straight away takes the advertisement_id and places it in a cookie or something so when the visitor clicks on a link called 'My List', it will read all the Advertisement_ID's the user has stored and retrieve the appropriate advertisements from the database. It's just a way of making it so the visitor can view only those ads that they are interested in.

As far as i know, this can be done using a cookie or something, but i'm not sure how to code it. If there is another way of doing too such as using a stored procedure which add's the record to a Favourites Table in the database, then i'd like to hear that too. I just need something which is not gonna slow down the server too much or nothin.

And just one other thing, what is the maximum size a cookie is allowed to be???

Any help will be greatly appreciated.

Thatguy

[raf]

And just one other thing, what is the maximum size a cookie is allowed to be???
Don't know if there is a maxsize (i never seen any sign of that). But there are other cookie-issues like:
- not all user have them enabled;
- everyone on your domain (if you use a subdomain) can get access to them
- if your app is hosted on a server-cluster, you need to make sure that all pagerequest go to the same server (which means that all links in your app need to be relative and that you need a redirect in your global.asa's Session_OnStart sub

I think that when you are doing server side development, you need to do as much serversided as possible.
So i would keep a table with the active sessions (also a good security measure) and another table where you store the session-tables ID and the Advertisement_ID. (1 record for each ad for each session)
You can then use this last table to show all the ads this client was inetersted in during this session or during all his previous sessions.
(If you only need data from his current session, you can clean up both tables when the session is ended. For instance with a 'ON DELETE CACADE' if sql-server supports that)

When i started developping, i also though i neede to go easy on the db-interaction, but i've realised there's no real need for that. If your db-design is OK (using indexes, good normalised data-model, using foreign key in a clear reletional design, ...) and your apps pageflow is OK and compatible with your db-design (only sending ID'values back, only joining multiple tables or only using aggregated functions or distincts or subquery's on not frequently ran pages, being able to select on one '(dimension)table to generate dropdowns etc ) then you only need to run fast executed query's on frequently ran pages.
And if your db can't support it, change db-format (like MySQL --> free and faster then sql server).

[whammy]

I wouldn't necessarily agree with that last statement. SQL Server is REALLY fast if used correctly. ;)

[Thatguy2001au]

That's what I thought. I thought SQL Server was quicker.

By the way, can you do Stored Procedures within MySQL???


These are a great feature with SQL Server. They make things so much easier. And apparently they are supposed to help speed things up (so i heard).

If i can't use stored procedures with MySQL, then i suppose i would have to place all my code within my asp pages right?



Thatguy

[whammy]

I wouldn't know what to do without stored procedures now... not to mention views, etc. etc.

I think SQL Server might be one thing M$ got right to some extent...

[raf]

Whammy :
I wouldn't necessarily agree with that last statement. SQL Server is REALLY fast if used correctly.
Yes. But you have fast - faster - fastest.

DB-performance comparisons are always a source of much discussion, but i think that MySQL comes out on top over SQL Server in (almost) all test. SQL server can keep up till 150 or 200 simultanious users. So for most stuff we design, the perfomance difference wount be noticable.
Some comparisons. Maybe you can come up with benchmarks that contradict them :D
http://www.eweek.com/article2/0,3959,293,00.asp
http://www.mysql.com/information/benchmark-results/result-db2%2Cinformix%2Cms-sql%2Cmysql%2Csolid%2Csybase-relative.html
http://www.mysql.com/information/benchmarks.html

Thatguy2001au:
By the way, can you do Stored Procedures within MySQL???
No. :( But they are on the developmenttree and might be included in the next version :)

These are a great feature with SQL Server. They make things so much easier. And apparently they are supposed to help speed things up (so i heard).
They speed up things, indeed. But they are mainly safer to use then embedded SQL (cause you can set up stored procedures for all datamanipulation from your web-app, and only allow manipulations through SP for the web-account)
The downside is that SP are db-objects, so if you'd (or some other party) ever wanted to run your app on another db, you'll need to do a huge amount of rework. So embedded SQL is more universal. The only rework would be that you need to change db-specifique SQL features (like changing 'TOP 5' in Jet SQL to 'LIMIT 5' in MySQL) but i try not to overuse thes db-specific goodies (specially when i'm using Jet SQL cause the chance i need to upsize is bigger then :D ) to keep the SQL as universal as possible.

So MySQL doesn't have SP yet. But they of coarse have some other nice features. Like recordset buffering (which boosts performance up to Oracle-level), cascades (don't know if Jet db-s got that, and noone answered that ;) ), easy and fast recordset paging cause you can use ofsets for LIMIT, ...) + it's free ...


But if SQL server is so fast and can handle enough concurrent connections, then there's really no reason to go over-easy on the db-connections and operations, and to use cookies. Right? Or is it a fancy sportscar that can only be used once in a while cause it doesn't behave well when it's raining or when it's to hot or there's to much wind or to much bumps in the road ? :D