Sign Up

Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.

Have an account? Sign In

Have an account? Sign In Now

Sign In

Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.

Sign Up Here

Forgot Password?

Don't have account, Sign Up Here

Forgot Password

Lost your password? Please enter your email address. You will receive a link and will create a new password via email.

Have an account? Sign In Now

You must login to ask a question.

Forgot Password?

Need An Account, Sign Up Here

Please briefly explain why you feel this question should be reported.

Please briefly explain why you feel this answer should be reported.

Please briefly explain why you feel this user should be reported.

Sign InSign Up

The Archive Base

The Archive Base Logo The Archive Base Logo

The Archive Base Navigation

  • SEARCH
  • Home
  • About Us
  • Blog
  • Contact Us
Search
Ask A Question

Mobile menu

Close
Ask a Question
  • Home
  • Add group
  • Groups page
  • Feed
  • User Profile
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Buy Points
  • Users
  • Help
  • Buy Theme
  • SEARCH
Home/ Questions/Q 6839025
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Editorial Team
Asked: May 26, 20262026-05-26T23:40:08+00:00 2026-05-26T23:40:08+00:00

I have a new program that will be generating a lot of Base64 encoded

  • 0

I have a new program that will be generating a lot of Base64 encoded audio and image data. This data will be served via HTTP in the form of XML and the Base64 data will be inline. These files will most likely break 20MB and higher. Would it be more efficient to serve these files directly from the filesystem or would it be feasible to store the data in a MySQL database? Caching will be set up but overall unnecessary because it is likely that this data will be purged shortly after it is created and served.

i know that storing binary data in the DB is frowned upon in most circumstances but since this will all be character data I want to see what the consensus is. As of now, I am leaning toward storing them in the filesystem for efficiency reasons but if it is feasible to store them in a database it would be much easier to manage the data.

  • 1 1 Answer
  • 0 Views
  • 0 Followers
  • 0
Share
  • Facebook
  • Report

Leave an answer
Cancel reply

You must login to add an answer.

Forgot Password?

Need An Account, Sign Up Here

1 Answer

  • Voted
  • Oldest
  • Recent
  • Random
  1. Editorial Team
    Editorial Team
    2026-05-26T23:40:09+00:00Added an answer on May 26, 2026 at 11:40 pm

    You need to weigh several factors:

    • Speed of access If you dump all your files in the filesystem, then some filesystems break or slow way down when you have too many files. I have seen many different directory segmentation schemes to address this issue.

    • Compression MySQL can easily compress your stored data. With a filesystem it may be harder to compress data. Using any kind of compression compression also raises a concern with the CPU speed on your server.

    • Backup/Restore A DB is made for easy backup/restore, how easy or hard it is for a filesystem varies greatly. If you have data in the filesystem to back/restore then that makes your backup/restore more complicated, and complicated is not good in a crisis.

    • Data loss tolerance With a DB you manipulate a record and all data is there in the same place. If you save your data to a file, you need to manipulate the associated file with extra code, and this this introduces another place to have bugs and possible data loss. More specifically, if you store part of the record in the filesystem and the rest in the DB, you need to go to great lengths to maintain transactional integrity. Nobody cares about this until you lose data, so pay attention to this aspect even though it may not seem important.

    • Replication It is easier to deal with replication concerns if you only have to do it at one level. Storing your data only in the DB and then replicating only the DB is far easier than doing that for the DB and also for the file system.

    • Cumbersomeness It is just more cumbersome to deal with larger DB backups than it is with smaller DB backups.

    Those are the top issues that come to mind. I tried not to advocate for either solution, it really depends heavily on which file system you are talking about as well, and since that is not specified, you need to make that decision yourself.

    • 0
    • Reply
    • Share
      Share
      • Share on Facebook
      • Share on Twitter
      • Share on LinkedIn
      • Share on WhatsApp
      • Report

Sidebar

Related Questions

I have some code that effectively does this : File file = new File(C:\\Program
I have a program that will read scripts, if i open new scripts with
I have a C++ program that will read in data from a binary file
I have a program that uses: ThreadPool.QueueUserWorkItem(new WaitCallback(FireAttackProc), fireResult); On Windows7 and Vista it
I have a PyQt program, in this program I start a new thread for
I am writing a program that will create a new datatbase, then add tables
I am attempting to run a program that will find a new value for
I'm writing a program that will watch a particular directory for new files containing
I have a program that will store many instances of one class, let's say
I'm really new to this. I am trying to write a CGI program that

Explore

  • Home
  • Add group
  • Groups page
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Users
  • Help
  • SEARCH

Footer

© 2021 The Archive Base. All Rights Reserved
With Love by The Archive Base

Insert/edit link

Enter the destination URL

Or link to existing content

    No search term specified. Showing recent items. Search or use up and down arrow keys to select an item.