每个“belongTo”文件上传的多个表和每个文件上传在模型中是否可以没有关系?

发布于 2024-10-25 13:22:22 字数 288 浏览 2 评论 0原文

我正在使用文件上传表(字段:id、名称、大小、类型)并使用一系列其他表(注释、文件),每个表都有一个指向其中一条记录的外键文件上传表(字段:upload_id)。每个系列表(例如注释、归档)的模型将包括指向文件上传表的BelongTo 关系。

这意味着文件上传表将没有外键(多个表指向它),因此除非我为每个其他表都有一个字段(例如 note_id>filing_id 等)。该模型不会提及任何关系。

我应该用别的方法吗?我想不出更有效的方法。

I am playing with using a table of file uploads (fields: id, name, size, type) and using a series of other tables (notes, filings) each with a foreign key pointing to one record in the file uploads table (field: upload_id). The model for each of the series of tables (e.g., notes, filings) would include belongTo relationship pointing to the file uploads table.

That means the file uploads table will have no foreign key (multiple tables point to it) so a foreign id field wouldn't work unless I had a field for every other table (e.g., note_id, filing_id, etc.). The model would not mention any relationship.

Should I do it another way? I can't think of a more efficient one.

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

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

发布评论

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

评论(1

爱你是孤单的心事 2024-11-01 13:22:22

基本上取决于业务逻辑。

如果您的文件分布在其他表之间(注释填充等),则

上传有很多注释
上传有很多填充

,但这是在每条记录只有一个文件的情况下。

如果您遇到注释或填充有多个文件的情况,那么您需要转到 HABTM 关系或:

Table notes:
id, name, desc ...

Table uploads:
id, name, size, type

Table notes_uploads:
id, note_id, upload_id

Table fillings_uploads:
id, filling_id, upload_id

因此,您将为其中包含文件的每个实体定义多对多关系。

我认为第二种方法更灵活,但实际上取决于要求。

Depends basically from the business logic.

If your files are distributed between other tables (notes fillings etc.) then the

Upload hasMany Note
Upload hasMany Filling

but this is in case when you have only one file per record.

If you have case when a note or filling has more than one file then you need to go to HABTM relaion or:

Table notes:
id, name, desc ...

Table uploads:
id, name, size, type

Table notes_uploads:
id, note_id, upload_id

Table fillings_uploads:
id, filling_id, upload_id

So you will define a many to many relation to each entity which has files in it.

I think the second way is the more flexible one, but really depends from the requirements.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文