Member Avatar for RazorRamon

Hello I'm looking to allow users upload pictures onto my site and have it displayed and linked to their site.. This process is for Ad purposes. Ive looked into php mysql uploading images but ive ran into a lot of threads condemning the practice and suggesting saving the images to a directory(and have the path saved in mysql).

Ive never tried uploading, displaying, querying, or loading images from either so I would like to know the major differences.

Are querys that much slower vs loading from directory?

Is it possible to have users upload directly into a directory? is this safe?

If jquery was integrated with the image query would that speed up the response time?

  • 3 Contributors
  • 6 Replies
  • 188 Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by Member #120589

Dani AI

Generated

Building on 's ad use-case and the helpful direction from and , here's a concise, practical plan you can apply now.

For an ad system, keep image bytes out of your main transactional tables: store files on disk or in object storage (S3/R2) and save metadata in MySQL. That makes thumbnailing, caching, CDN delivery, and backups far simpler. Use server-side image processing at upload to produce a small set of sizes (thumb, medium, original) so pages only request what they need.

Make uploads safe and predictable: validate the actual image (finfo_get_file or getimagesize), whitelist extensions/MIME types, limit file size, strip or sanitize EXIF, and never trust the client filename. Store uploads outside the webroot or with a randomized filename, disable directory listing, and set strict file permissions. Example (PHP) for a safe filename + move:

$ext = strtolower(pathinfo($_FILES['image']['name'], PATHINFO_EXTENSION));
$safe = bin2hex(random_bytes(8)).'_'.time().'.'.$ext;
$dest = '/var/www/uploads/'.$safe;
if (move_uploaded_file($_FILES['image']['tmp_name'], $dest)) {
  // create thumbnails, store metadata: owner_id, path, mime, expires_at
}

Handle expiry by marking records with an expires_at and using a background job (cron/queue worker) to delete files and then remove or archive DB rows. This avoids race conditions and gives clients the option to reactivate archived ads. For public links, generate a separate public token/slug (UUID or hash) rather than exposing raw auto-increment IDs.

Finally, require client accounts for ad management and secure them: HTTPS, strong password hashing (PHP password_hash()), prepared statements, CSRF protection, rate limits on uploads, and virus scanning if possible. Client-side tools (AJAX, jQuery) improve UX but won’t reduce server CPU — real speed gains come from thumbnails, caching headers, and using a CDN.

Recommended Answers

All 6 Replies

Member Avatar for Member #120589

If you have small and few images a db storage may work for you. However directoty path is easier. You can filter the upload types you allow. Javascript typicLly slows things rathwr than speeeds things up.

Member Avatar for RazorRamon

Well like i said they are for Ads. I'm planning on giving them expiration dates and delete them once they've expired. Another question somewhat off topic from this. once i delete the expired entries there will be number gaps in the "id" number sequence.

When I "INSERT" new entries will the new entries fill in those gaps? or be tacked on the end?

Member Avatar for blocblue

When defining your database table, typically the unique identifier is a numerical field, where the value automatically increments. MySQL will then keep a track of what the next id number should be based on those it has previously allocated.

Auto increment would not reallocate the same id value, unless you explicitly changed the tables internal counter.

Member Avatar for Member #120589

Don't worry about autoincrement - as blocblue says, the DB will take care of this for you. As long as you've got a robust normalized DB structure, you should be fine.

WRT to expiry dates - if you search for adverts within a set date (e.g. not yet expired), you probably don't need to delete any info. This may be useful to move old ads and related records into archive tables. This way an AD client can search for previous entries and re-activate the AD without having to feed in all the same data again.

Member Avatar for RazorRamon

Would you suggest making a log in for ad clients? to remember all of their info? I'm fairly new to logins and image querys but would there be away around the logins?

Member Avatar for Member #120589

Most certainly. But it has to be secure. If not it will cause you a monster headache and possible loss of faith or worse

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.