图像和文本数据库
背景：
我正处于构建应用程序的设计阶段。
我希望应用程序显示文本和图像，问题是我会有很多文本和图像。数百到数千。
这是迄今为止我最大的应用程序，我不确定如何处理所有数据。
问题??????：
存储和访问这些图像和文本的最佳方式是什么？
我会使用 SQL 等正式数据库方法吗？
或者导航文件/文件夹会更好，例如将所有文件放在 res/drawable 中？
潜在有用的事实：
数据库将在本机存储和访问，因此可以离线访问。
用户不会以任何方式添加到数据库，只会访问数据。
数据库每 6 个月更新一次。
应用程序“页面”将显示 1-5 个图像以及多个文本块。
概念：
该应用程序将像一个食谱应用程序......用户将选择一些参数，例如成分、类型、饮食......然后选择一个食谱。然后将显示几张图像和文本块，显示并详细说明某些食谱的过程。
如果重复出现这种情况，我深表歉意，但我没有看到适合我目的的具体答案。
background:
I'm in the design phase of building an app.
I want the app to display text and images, the problem is that I will have A LOT of them. hundreds to thousands.
This is my largest app so far, and I am unsure on how to handle all the data.
The question???????:
What would be the best way to store and access these images and text?
Would I use a formal database approach like SQL?
Or would it be better to navigate files/folders e.g. dropping all the files in res/drawable?
potentially useful facts:
The database will be stored and accessed natively so it can be accessed off-line.
The user will not be adding to the database in anyway, only accessing the data.
the database will be updated every 6 months.
The application 'page' will display 1-5 images along with several blocks of text.
Concept:
the app will be like a recipe app...the user will pick some parameters e.g. ingredients, type, diet.. then select a recipe. And then several images and blocks of text will be displayed showing and detailing the process of some recipe.
I apologize if this is repeated but I didn't see a specific answer for my purposes.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
“最佳”方法将取决于相关数据库服务器的功能。
一般来说，您应该将图像存储在数据库“中”，直到这成为性能问题。一旦开始在数据库“外部”存储图像，您将必须处理通常由数据库处理的所有问题。磁盘空间管理、孤立记录、文件名冲突、文件夹文件限制等等。根据您的情况，这些可能是大问题，也可能没什么可担心的。
我见过几个将图像（或附件）保存在数据库“外部”的应用程序，并且在每种情况下都做得很糟糕。有太多的问题需要处理，而大多数开发人员甚至没有想到其中的一半。在许多情况下，将图像存储在数据库“中”的性能是可以接受的，但开发人员决定不这样做，因为他们知道它的性能不佳。
The "Best" approach will depend on the functionality of the database server in question.
Generally, you should store the images "In" the database until that becomes a performance issue. Once you start storing images "Outside" of the database you will have to handle all the issue that are normally taken care of by the database. Disk space management, orphan records, file name conflicts, folder file limits, to name just a few. Depending on your situation these may be big issues or thay may be nothing to worry about.
I've seen several application where images (or attachements) were kept "Outside" the database, and in each case it was done poorly. There are just so many issues to handle, and most developers don't even think of half of them. In many cases the performance of storing the images "In" the databse was acceptable, but the developers decided against it because they just knew it would not perform well.
如果您使用 SQL Server 2008，Filestream 数据类型非常适合您的情况。它将二进制文件存储在数据库外部，但行为与普通字段相同。此外，您还可以使用流来读取/写入文件，而不是将整个文件获取/设置为字节数组（例如使用
varbin(max)时）如果您没有此功能您的数据库，我建议将图像存储在数据库之外
If your using SQL server 2008 the Filestream data type is ideal for your case. It stores the binary files outside of the database but behaves as a normal field. Also you are able to read/write the files using a stream instead of getting/setting the whole file as a byte array (like when using
varbin(max))If you don't have this functionality in your database, I would recommend storing the images outside of the DB
使用基于文件的方法来部署静态资源可能是一个更好的主意。
至少，因为对文件系统的依赖通常比对数据库的依赖更容易管理。
此行还表示某种非 Web 客户端
这意味着，如果您采用数据库方法，您将遇到一些其他有趣的问题
部署，
具体取决于部署的平台数据库可能是一个真正的熊，具体取决于您的目标平台，如果他们已经拥有引擎但它是不同的版本，那么
.
您的数据库将是基于客户端/服务器的（例如 MySQL/ SQL Server 等）？如果是这样，那么您的应用程序现在必须管理其进程的当前状态，如果不是，那么您将使用基于文件的数据库 SQL Lite/MS Access，此时我会质疑为什么使用静态。 最后一点需要
注意的是，内容制作者通常会为其内容维护一个数据库，稍后您将使用该数据库来生成用于发布/部署的文件。 。
Its probably a better idea to use a file based approach for deployed static resources.
At the very least because taking a dependency on file system is typically easier to manage then taking a dependency on a DB.
Also this line indicates some sort of non-web client
This means if you go with the DB approach you'll have a couple of other interesting problems
Deployment
Depending on the platform deploying a DB can be a real bear depending on your target platform. What happens if they if already have the engine but its a different version.
Resources
Is your DB going to be client/server based (like MySQL/SQL Server etc)? If so then your app has to now manage the current state of its process. If not then you'll be using a file-based db SQL Lite/MS Access, at which point I would question why using a static DB is worth doing at all.
One final note. There's nothing stopping your Content Production environment from using a DB. Its quite common for Content producers to maintain a database for their content that will you will later use to produce the files for publishing/deployment.