Database Design

[Shabam]

I have an application that lets users upload pictures. These pictures are
stored in different folders depending on the user ID (of the user that it
belongs to). The path can be figured out dynamically by knowing the user
ID. However, the programmer that's coding my application has decided to
save the full path into the database.

Upside that I see is, if there's a huge load of traffic I can see how it may
be good for performance, since you don't need to dynamically figure out the
path.

The downside though, is that this leads to database bloat, and I'm not sure
if that will cause the database performance to decrease. Also, whenever the
system path is updated, a script needs to go through the database and update
everything to reflect the new path.

So, if you can give me your input on this, I'd greatly appreciate it. Is
this a good, or bad way of designing a database?

[John Bell]

Re: Database Design

Hi

So long as you are not storing the image in the database, the actual
difference in size will be (say tens) of bytes per row. I would not say that
this is going to cause significant bloat.

One advantage will be that you are no-longer id dependent so users can share
images easily and there is no need to move any files if a user changes Id
for some reason.

You could also argue that if you ever decided to move the files to a
different drive, then it would be easier with the full filename as it is one
one update statement and no code changes, especially if you change the
directory structure where have half your users on one disc and the rest on
another.

John


"Shabam" <blislecp@hotma il.com> wrote in message
news:wMCdnfvJof FkJ8vcRVn-oA@adelphia.com ...[color=blue]
> I have an application that lets users upload pictures. These pictures are
> stored in different folders depending on the user ID (of the user that it
> belongs to). The path can be figured out dynamically by knowing the user
> ID. However, the programmer that's coding my application has decided to
> save the full path into the database.
>
> Upside that I see is, if there's a huge load of traffic I can see how it[/color]
may[color=blue]
> be good for performance, since you don't need to dynamically figure out[/color]
the[color=blue]
> path.
>
> The downside though, is that this leads to database bloat, and I'm not[/color]
sure[color=blue]
> if that will cause the database performance to decrease. Also, whenever[/color]
the[color=blue]
> system path is updated, a script needs to go through the database and[/color]
update[color=blue]
> everything to reflect the new path.
>
> So, if you can give me your input on this, I'd greatly appreciate it. Is
> this a good, or bad way of designing a database?
>
>
>[/color]

[John Bell]

Re: Database Design

Hi Shabam

Please do no post the same question separately in multiple newsgroups .

John

"Shabam" <blislecp@hotma il.com> wrote in message
news:wMCdnfvJof FkJ8vcRVn-oA@adelphia.com ...[color=blue]
> I have an application that lets users upload pictures. These pictures are
> stored in different folders depending on the user ID (of the user that it
> belongs to). The path can be figured out dynamically by knowing the user
> ID. However, the programmer that's coding my application has decided to
> save the full path into the database.
>
> Upside that I see is, if there's a huge load of traffic I can see how it[/color]
may[color=blue]
> be good for performance, since you don't need to dynamically figure out[/color]
the[color=blue]
> path.
>
> The downside though, is that this leads to database bloat, and I'm not[/color]
sure[color=blue]
> if that will cause the database performance to decrease. Also, whenever[/color]
the[color=blue]
> system path is updated, a script needs to go through the database and[/color]
update[color=blue]
> everything to reflect the new path.
>
> So, if you can give me your input on this, I'd greatly appreciate it. Is
> this a good, or bad way of designing a database?
>
>
>[/color]