in a client-server database application, the different options the client needs to read from the server, where you'd store them? In the database or in some file which will then will be transferred on the network, or is there any better way.
It depends on the specific.
Generally speaking there is very little to store something in a file on the server (apart from files themselves such as images, videos, songs and so forth) rather than a database.
If you're storing, say, client preferences you may store them in a file on the client but this has portability problems (in that the profile settings don't go to another PC with the same user) but it might be appropriate if the client can be used "offline".
Probably the best of both worlds is to store things in a database on the server and cache them on the client (in files probably) to allow offline usage, if that's appropriate to the application in question.
Depends on how dynamic access to the values has to be.
Putting them in a file means having to edit the file for changes. You have to edit the file, perhaps repackage the app with the new values, and bounce the server. If you're using an exploded version of the code on the server, it means giving clients write permissions on the server, which can be problematic.
If you put them in the database, clients can see changes without having to edit a file. They get to see the values right away. No server bounce needed. And you can dole out access using database permissions.
UPDATE: Another thought - are the options for all users or just a single individual? If it's the former, you have to worry about "oil canning", where one user changes a value and another switches it back. If it's for a single individual, you'd have to have a file for each user. A large user base could be a problem.
The clients need to read just some configuration settings, that's all. Also those options will not be changed from the clients, only from the server.
It depends upon use cases, but my own experience says, it is better to store options in database. In todays' world, we need to go towards shared-nothing type of architecture as far as we can. In that way, if tomorrow you make your application to be failsafe, you will find, it is better to store all options in database. Because otherwise you need to sync your files accross various nodes which are running the copy of your application. On the other hand, if it is in database, it is all there in db and most of the db supports High-Availability type of use case in which case you do not need to be worried about keeping your application with files running in different nodes in sync.
That depends on a number of factors:
Do you have more then one Front End
Server, then the database approach
requires less maintainance.
If you have a Dev, QA as well as a
Prod environment then the file
approach makes sense as the config
will not be changed when
copying/restoring a database from
one of the other environments.
Normally, I would store the configuration settings in a database, if available. However, in the project I am now working, the client wants multiple distributed copies of the database, updated from a master. Each installation has it's own configuration, such as printer settings.
The answer in this case is to have a local config file, where the local user settings are stored. The application generates the default for each setting. If need be, the file can be edited to update settings on the fly.
Related
So here's the deal. I have a WPF application which stores all the data into MS Access Database. But it is supposed to be a multi-user based application.
What I want:
The application exe to run from each user node and get stored in the database present at a particular user's drive/location.
What I have Tried:
I put my application and access db file in a shared folder, and everything works fine. But I don't want my users to be able to copy the database. And according to what I researched and found, if I put any file on a shared location there's no way I can prevent anyone from copying it.
Considering the fact that I have negligible knowledge of Networking. I would like you to help me out with what I should search for, or the things that I should learn. Or if you could just provide the solution. Any help or suggestion is appreciated.
This is what I imagine it should be like:
Sorry, but this is not possible.
An Access database is just a file. Anyone with read access to that file, has, well, read access to that file, which allows them to copy it.
You can try to obfuscate the file location, but a tech savvy user will always be able to download the database.
You're looking for a client-server RDBMS. There are tons available (MS SQL, MySQL, Oracle, Postgres, etc.). In fact, it's much more common than databases like Access.
Alternatively, you can develop your own server that reads and writes to the database and passes data to the nodes and disallow nodes to directly access the database, but this is very much nontrivial and Access is not supported for server use.
Well we all know how many arguments and lives have been lost with the discussion of using databases for file storage (images specifically). I'm in a bit of a pickle when it comes to deciding on how to proceed with my project.
I have a website that allows admins to upload employee pictures. For now, these pictures are stored in BLOB in my MySQL database. Also, I have a windows application that runs alongside the website. This application enables employees to punch in and have their pictures appear when they've successfully done so. The picture is retrieved via a mysql query within the application (from a non-local remote location) that converts the image content to a readable image that's being outputted in a picture box, confirming the identity of the employee.
In my eyes, it is much much easier to have the images stored in the database and have them retrieved via a simple query. I found this a lot easier than storing image paths in the database and having to deal with the application downloading the images. I also don't have to deal with collisions, folder organization and security and paths being re-written for x,y reasons, etc etc.
The images stored in the DB are a mere 20 kb after being cropped to a certain size. My question is, is it still worth embedding the database with image paths or should they simply be stored as they are right now? If storing images in the database is still ill-advised in this case, is there a formal way to store image paths?
Any help on this would be greatly appreciated. If this question doesn't belong here, I'll be happy to move it.
If the images are user data, rather than part of your application's code or theme, then storing the images in the database is a good idea, because…
Backups are easier to manage if all you have to back up is the database. On the other hand, if you store some application data in the database and some in the filesystem, then you'll have to coordinate the backup schedules of your database and your filesystem to ensure that the two are consistent.
If you have a database administrator at your disposal, then great! Your backups should already be taken care of. If not, then database backups may be slightly tricky to set up, but once you do have a backup system, it can be better than filesystem backups. For example, many database systems have support for streaming replication.
If your application is load-balanced and served by a pool of multiple webservers, then you'll either have to replicate the data to all of the machines, or share them among your servers using a network filesystem.
Of course, having the images on a filesystem also has its advantages, namely in performance and simplicity, since most webservers are built to serve static files. A hybrid approach could give you the best of both worlds:
The images stored in the database would be the authoritative data.
Your application can have a feature to extract them as files in their local filesystem as a kind of cache. That cache can be rebuilt at any time, since it is not authoritative.
The webserver can then serve the files directly from the filesystem.
There are several reasons why I think storing images in a database is a bad idea:
1) The server will have timestamp info associated with files that the database won't keep track of. if you ever need to this for forensics reasons, the DB solution will likely be limited in this regard. Feel free to save info about images uploaded regarding IP info, timestamp, etc. in the DB though too.
2) If you ever want these files used by, say, another system/service you'll have to constantly reference the database and interact with it, when you could far more easily just target a specific folder.
3) Any time an image needs to be retrieved, you have to open a connection to the database just to generate it. This may add extra code and steps to things that could be easier to implement by pointing to a folder.
To avoid naming collisions, if I were on a Linux box, I'd use something like a Unix timestamp as a prefix to the filename when it's saved, or simply use that (+ maybe a short random #) as the image ID altogether. So instead of 'jane-image.jpg', it'd be '1407369600_img3547.jpg'. Then, just put a reference to that in the DB and viola, that's a random enough ID where there should never be a collision, unless time starts flowing backwards. Whatever the Windows timestamp equivalent is would be used, obviously.
NOTE: What you're doing now isn't bad and from what it sounds like it may work best for you...but generally speaking I try not to put everything in the hands of a database, just because I can. But that's me :)
I will keep this short, I am looking to store product plan data, these are the plans that the users would pick for their payment options. This data include how much the plan cost and what the unit details of the plan are, like what makes a unit (day/week/month) and fairly simple data about the plan. These plans may or may not change once a month or once a year, the company is a start up and things are always changing on the 11th hour and contently so there is no real way to predict when they will change. A co-worker and I are discussing whether these values should be stored in the web.config (where they currently are) or move them to the database.
I have done some googling and I have not found any good resource that help draw a clear line of when something should be in the database or in the web config. I wanted to know what your thought on this was and see if someone could clearly define when data should be stored in config or in the database.
Thanks for the help!
From the brief description you provide, it seems to me that the configuration data, eventually, may be accessed not just by your web server-based application running on one computer, but also by other supporting applications, such as end-of-month batch jobs, that you may want to run on other computers. To support that possibility, it would be a good idea to store the data in some sort of centralized repository that can be accessed remotely from multiple computers.
Storing the configuration data in a database is the obvious way to meet that requirement. But if you don't want to do that, then another approach would be to store the configuration data in a file on a company-internal (rather than public) web/ftp server. Then an application can use a utility such as curl to retrieve the configuration file from the web/ftp server.
Of those two approaches, I think using a database is probably best, because it provides an ergonomic way to not just read the configuration data, but also update it.
I have a web application currently being developed in JSP/Servlets.
The application allows users to upload image files for each user account.
What is the best way to store the images?
Please consider the following features that I'd like to have before your answer;
I am using MySQL now, but there could be a possibility of moving to a different database.
I can store the images as flat files, but I want the admin account to have an option to backup the complete database and reload it later. Ideally the backup/reload should work with the images too. (even if the backup was done from a different physical machine and reload was done from a different machine)
Using BLOB/CLOB is an option that solves problem 2.
But, what if my database becomes very large?
In your case, I strongly recommend you having a blob field on your database and store the images in it. Mainly, because this is the correct place for them. So, make a Servlet that retrieves the image of the specified user from the database. For example, /userimage?name=john.
About your "size/performance" problem:
Databases were made (among other things) to store and exchange large amounts of data.
So, they're the best option.
Even if you store them on other sites, they will still reduce free space and performance.
If you really want to manage LARGE data (>= 3TB, not your case) then you can store them on a file system and save the filenames in the DB. For more info, look at this question.
Store them in the file system. It's faster and simpler. Often, when accessing an image, you're going to have to save it to a file anyway before you can utilize it. You can examine the images with third party tools. You can store the recordID in the filename to keep the image/record association from ever being broken.
Many others share this opinion: http://forums.asp.net/p/1512925/3610536.aspx
Just store them in the DB... if your user base "becomes very large" you'll have buckets of cash to buy a balls-out database server (or even a farm of them) which can handle the load, now won't you?
Let's say you have many applications in your environment all of which store their connection strings to SQL Server in a web config. Is it possible to have the application retrieve those connection strings from Active Directory?
We're moving some database servers around and would like a way to have them read from a central location. Active Directory was suggested as one possibility, but we didn't know if it was possible.
This would, in theory, allow us to gradually change our applications to use AD to read the connection strings, then as we move our database servers, make one change in AD to update all the applications.
Is this possible? Maybe you have a better suggestion. Thanks!
Technically speaking, you can't store the information in LDAP since it is a protocol, not a storage mechanism. However, there is no reason (that I know of) that you couldn't store the information in Active Directory or other directory services type engine, and retrieve them with a query from the application. You would just need to come up with some organizational scheme and I would suggest some common code in a library or something that allows you to access the information.
I'm not saying that storing it in Active Directory is the best option, but I believe you should be able to do it without a problem.
We had a design to do that. Our architecture allowed multiple servers, each with multiple databases. We were using Active Directory to manage attributes about the users, including which databases they had access to.
It seemed logical design at the time, since we either had to do that or have a "master" database to direct. Using Active Directory, we no longer had a single point of failure.
Have no idea how it turned out, I left that company.
"The LDAP should be for directory information"
What does that mean? Configuration information is a perfect candidate for being stored in the Dit - it is read intensive, secure, replicated, and easy to access. Most of what is stored in Active Directory is "configuration information".
You can store the connectionstrings about anywhere you want. You could even do them as TXT records on your DSN servers. But you would have to build the resolution framework yourself. Also keep in mind that the connection strings make contain secure information. (such as passwords). If you store these in LDAP (I am speaking genericly for any ldap based server) you will want to make sure the attribute is not public. The upside is LDAP proxy accounts (anonymous connections) would not be able to see the information. The downside is you will have to do an LDAP bind before you can get the information back out of the system. As long as you cache a connection string on the client/server that is going to be making the database calls, you shouldn't see any real performace issues. But if you had to query an LDAP server before each database call you might have problems.
a custom object or even an extension attribute for an exsisting object may be best.
Extend AD Schema
You could create a non-person user and have the connection string be an attribute in the user, but, that would be misusing the LDAP, IMO.
What may be better is to use dependency injection and just have common information such as a connection string, be in one file and just have it either read in when the application starts, or have it be injected in when recompiling.
For example, you could use Spring or Spring.NET, but there are a myriad of DI frameworks that would work.
UPDATE: You could also just create a database table that has this information, and all the applications could read from the database to get all their configuration information.
An LDAP should be used for directory-related issues, I believe, as well as, now, user-management and account information.