上传命名约定

发布于 2024-10-12 06:04:52 字数 160 浏览 11 评论 0原文

我正在创建一项调查,用户可以在其中上传大约 6 张图片。我将这些存储在文件系统中的最佳方式是什么?用户可以进行多项调查(从而跟踪他们随着时间的推移的改进)...这意味着我不能只是按顺序命名它们...

这是一个 CI/PHP 应用程序。 :)

或者为了知识的缘故,你会怎么做?

I'm creating a survey in which users can upload about 6 pictures. What would be the best way for me to store these in the file system? Users can do multiple surveys (thus tracking their improvement over time)...so that means I can't just name them sequentially...

This is a CI/PHP app. :)

Or for knowledge's sake, how would you do it?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

天邊彩虹 2024-10-19 06:04:52

哇,这有点开放式......我想我可能会为每个用户构建一个目录,然后根据上传的日期时间命名图像。所以它看起来像这样:

/+
 |
 +--+ Kyle
    |
    +-- 20110113114903.png
    |
    +-- 20110113115122.png
    |
    +-- 20110114010304.png
 +--+ Kevin
    |
    +-- 20101114123456.png
    |
    +-- 20110102023648.png
    |
    +-- ...

但是,这可能不像您希望的那样可扩展。您可能想让目录更深,这样每个人每个日期都会得到一个目录,里面有图像。

Wow, this is kinda open-ended... I think I'd probably structure a directory for each user, then name the images based upon the datetime they were uploaded. So it would look something like this:

/+
 |
 +--+ Kyle
    |
    +-- 20110113114903.png
    |
    +-- 20110113115122.png
    |
    +-- 20110114010304.png
 +--+ Kevin
    |
    +-- 20101114123456.png
    |
    +-- 20110102023648.png
    |
    +-- ...

However, this may not be as scalable as you like. You might want to make the directories deeper, so each person gets a directory per date, with images inside.

秋叶绚丽 2024-10-19 06:04:52

将数据库中的所有这些映射到文件系统中存储的位置将是可搜索调查和用户的最佳结果。

// Pseudo Database
// user table
user_id (pk)
user_name
user_filesystem_dir
...

// survey table
survey_id (pk)
survey_name
survey_filesystem_dir
...

// Image table
image_id (pk)
image_name
image_filesystem_dir
user_id_fk (this is the user_id from the user table)
survey_id_fk (this is the survey_id from the survey table)
...

// Find all the images for user id 123 and survey 456
SELECT * FROM image_table AS it, user_table AS ut, survey_table AS st
JOIN (it.user_id_fk = ut.user_id AND it.survey_id_fk = st.survey_id)
WHERE user_id_fk = 123
AND survey_id_fk = 456

// Pseudo Code
$user_id     = 123;
$survey_id   = 456;
$survey_name = 'Stack Survey #1';

$image_array = array(
    'image1.png',
    'image2.png',
    'image3.png',
    'image4.png',
    'image5.png',
    'image6.png'
);

// Folder Structure where User is most searched 
+-+123 <user_id>
  |
  +-467 <survey_id>
  | |
  | +-images
  |   |
  |   +-image1.jpg
  |   +-image2.jpg
  |   +-image3.jpg
  +-456 <survey_id>
    |
    +-images
      |
      +-image1.png
      +-image2.png
      +-image3.png
      +-image4.png
      +-image5.png
      +-image6.png

// Folder Structure where Survey is most searched 
+-+467 <survey_id>
| |
| +-123 <user_id>
|   |
|   +-images
|     |
|     +-image1.jpg
|     +-image2.jpg
|     +-image3.jpg
+-456 <survey_id>
    |
    +-123 <user_id>
      |
      +-images
        |
        +-image1.png
        +-image2.png
        +-image3.png
        +-image4.png
        +-image5.png
        +-image6.png

Mapping all this in a database to where you have them stored on the file system would be the best result in searchable surveys and users.

// Pseudo Database
// user table
user_id (pk)
user_name
user_filesystem_dir
...

// survey table
survey_id (pk)
survey_name
survey_filesystem_dir
...

// Image table
image_id (pk)
image_name
image_filesystem_dir
user_id_fk (this is the user_id from the user table)
survey_id_fk (this is the survey_id from the survey table)
...

// Find all the images for user id 123 and survey 456
SELECT * FROM image_table AS it, user_table AS ut, survey_table AS st
JOIN (it.user_id_fk = ut.user_id AND it.survey_id_fk = st.survey_id)
WHERE user_id_fk = 123
AND survey_id_fk = 456

// Pseudo Code
$user_id     = 123;
$survey_id   = 456;
$survey_name = 'Stack Survey #1';

$image_array = array(
    'image1.png',
    'image2.png',
    'image3.png',
    'image4.png',
    'image5.png',
    'image6.png'
);

// Folder Structure where User is most searched 
+-+123 <user_id>
  |
  +-467 <survey_id>
  | |
  | +-images
  |   |
  |   +-image1.jpg
  |   +-image2.jpg
  |   +-image3.jpg
  +-456 <survey_id>
    |
    +-images
      |
      +-image1.png
      +-image2.png
      +-image3.png
      +-image4.png
      +-image5.png
      +-image6.png

// Folder Structure where Survey is most searched 
+-+467 <survey_id>
| |
| +-123 <user_id>
|   |
|   +-images
|     |
|     +-image1.jpg
|     +-image2.jpg
|     +-image3.jpg
+-456 <survey_id>
    |
    +-123 <user_id>
      |
      +-images
        |
        +-image1.png
        +-image2.png
        +-image3.png
        +-image4.png
        +-image5.png
        +-image6.png
忆梦 2024-10-19 06:04:52

考虑顺序编号:

user123_survey1_image6.jpg

用户的 ID 为 123,这是用户的第六张图像,或者更简单:

user123_survey56_image899.jpg

用户 123 的第六张图像恰好具有ID 899

Consider sequential numbering:

user123_survey1_image6.jpg

The ID of the user being 123, and this being the user's sixth image, or even more easily:

user123_survey56_image899.jpg

where user 123's sixth image happens to have the ID 899.

誰認得朕 2024-10-19 06:04:52

如果您按照“从而跟踪他们随时间的改进”的建议跟踪各个用户,我将从顶级目录开始。然而,随着用户数量的增加,即使这样也可能导致目录膨胀。

在我编写的一个应用程序中,我必须为系统中的每个用户创建一个文件,我编写了一个例程(实际上是数据库端),将他们的唯一 ID 分解为一组结构化的文件夹。

例如:用户 12345 upload #5 可以存储在 UPLOAD_DIR/1/2/3/4/5/upload_5.png

如果你想要一些不太“可猜测”的东西,你仍然可以使用类似上面的东西,但不仅仅是使用他们的 id,你可以对其进行哈希处理,但遵循类似的模式。

If you track the individual users as is suggested by "thus tracking their improvement over time" I would start with that being the top level directory. However, even that can lead to a directory bloat as the number of users increases.

In one application I wrote where I had to create a file for every user in a system, I wrote a routine (was actually database side) that broke down their unique id into a structured set of folders.

For example: user 12345 upload #5 could be stored in UPLOAD_DIR/1/2/3/4/5/upload_5.png

If you wanted something a little less "guessable" you could still use something like the above but instead of just using their id, you could hash it but follow a similar pattern.

戏剧牡丹亭 2024-10-19 06:04:52

一种替代方法是使用 uniqid() 随机命名文件。当然,您必须检查以确保该 uniqid 尚不存在。像这样的东西。

do {
    $filename = uniqid().'.jpg';
} while (file_exists('images/'.$filename));

One alternative would be to name your files randomly with uniqid(). You would have to check to make sure that that uniqid does not already exist of course. Something like this.

do {
    $filename = uniqid().'.jpg';
} while (file_exists('images/'.$filename));
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文