I would like to build a Shared Documents Library in ASP .Net and SQL Server but I have a problem, the customer wants to open the documents (stored in SQL Server) in Office UI and when save it, the document should be saved directly in database like SharePoint Server.
I've been researched on web since last week and I didn't found any answer or specific technology to do this.
Do you have any idea?
Thanks,
Sergio
I believe it would be best to store the information within the documents or perhaps the file paths rather than the documents themselves. None the less, it is possible to achieve what you wish to accomplish.
In your ASP.NET site, you will need to add a functionality to import/export some MS Office documents.
Solution 1
The site could allow a user to upload a document in a folder on the server and the site could store the file path in the database. For the download part, you could simply select the proper file path so that the user can download the document he/she wishes.
Solution 2
The site could allow a user to upload a document and store it in the SQL Server database. The documents could be stored as BLOBs. In SQL Server, you can use the varbinary(max) datatype for that. It would be rather tricky for the download part...
Here are some sites to help you out:
http://support.microsoft.com/default.aspx?scid=kb;en-us;258038
http://www.sqlservercentral.com/forums/shwmessage.aspx?forumid=169&messageid=243427
http://weblogs.sqlteam.com/peterl/archive/2007/09/26/Insert-binary-data-like-images-into-SQL-Server-without-front-end.aspx
SharePoint provides a WebDAV interface to update its files. Now, it may be a hefty bite to chew, but if you were to develop a WebDAV interface, that could be the ticket.
Take a look at this article, where something similar is described. Perhaps it will help you get started.
http://thehojusaram.blogspot.com/2007/06/c-webdav-server-with-sql-backend-source.html
I don't know of any tools to do this, but I see two possibilities:
1) Save a pointer to the file in the DB instead of in the DB itself. I think this is closer to what Sharepoint actually does, but I could be wrong, there.
2) Store the document as OpenXML (in an Xml datacolumn). Then, using Office Interop, open the Word (or whatever) and pass it the OpenXML data to generate the actual document. When the user clicks 'save' save it back to the DB as OpenXML.
------ Bonus Idea ------
3) (For small enough files) You could also use NVARCHAR(MAX) fields in your DB to store the data, if necessary, though storing the formatting information can be a little difficult.
Related
I am writing a web site using asp.net mvc3 and in my website I want to have a page for setting capacity of a queue. this page is shared between some users. so I need to save this data somewhere which is reachable by all users. I do not like to store this value in Database because it is just a number and I prefer to save in another place.I also tried storing in file but it is not a good idea too because it need permission setting.
is there any other place than files on server which let me do this?
You are going to have to persist it somewhere if you want it to stay around, either a flat file or database or something similar.
Other than that, you can cache the value in memory (session, static, or another caching scheme) so you aren't constantly reading it from a heavyweight store. For example you could read it in on application start and then just use the in memory variable (writing it back to the disk when it changes).
Just create a table Settings with two columns Key and Value and reuse it for other settings you may need in the future.
Your database is a good place for storing your data - ie. database backups will backup your settings as well.
The alternative is using Configuration Manager.
NoSQL is a great option in this case, I think for this particular case Redis is a better fit, checkout Booksleeve from NuGet
I have to find a design decision for the following task:
I have a SQL Server database and it contains a table of orders. PDF documents will be uploaded by users through a simple file upload from a web page and assigned to an order. There is not more than one document per order (perhaps no document, never more than one). For this purpose a user opens a web page, enters an order number, gets the order displayed and clicks on an upload button. So I know to which order the uploaded document belongs to.
Now I am considering two options to store the documents on the web server:
1) Extend my table of orders by a varbinary(MAX) column and store the PDF document directly into that binary field.
2) Save the PDF file in a specific folder on disk and give it a unique name related to the order (for instance my order number which is a primary key in the database, or a GUID which I could store in an additional column of the order table). Perhaps I have to store the files in subfolders, one per month, and store the subfolder name into the order row in the database, to avoid getting too many thousand files in one folder.
After the PDF files are stored they can be downloaded and viewed via browser after entering the related order number.
I'm tending towards option (1) because the data management seems easier to me having all relevant data in one database. But I am a bit afraid that I could encounter performance issues over time since my database size will grow much faster than with solution (2). Around 90% or even 95% of the total database size would be made up only by those stored PDF files.
Here is some additional information:
The PDF files will have a size of around 100 Kilobyte each
Around 1500 orders/PDF files per month
Windows Server 2008 R2 / IIS 7.5
SQL Server 2008 SP1 Express
Not quite sure about the hardware, I believe one QuadCore Proc. and 4 GB RAM
Application is written in ASP.NET Webforms 3.5 SP1
(I am aware that I will reach the 4GB-limit of the SQL Server Express edition after around 2 years with the numbers above. But we can disregard this here, either removing old data from the database or upgrading to a full license will be a possible option.)
My question is: What are the Pro and Contras of the options and what would you recommend? Perhaps someone had a similar task and can report about his experience.
Thank you in advance for reply!
Related:
Storing Images in DB - Yea or Nay?
With SQL Server 2008, when you have documents that are mostly 1 MB or more in size, the FILESTREAM feature would be recommended. This is based on a paper published by Microsoft Research called To BLOB or not to BLOB which analyzed the pros and cons of storing blobs in a database in great length - great read!
For documents of less than 256K on average, storing them in a VARBINARY(MAX) column seems to be the best fit.
Anything in between is a bit of a toss-up, really.
You say you'll have PDF documents mostly around 100K or so -> those will store very nicely into a SQL Server table, no problem. One thing you might want to consider is having a separate table for the documents that is linked to the main facts table. That way, the facts table will be faster in usage, and the documents don't get in the way of your other data.
This was asked many times about storing images, but the discussion to those still applies:
https://stackoverflow.com/questions/805519/save-image-in-database
store image in database or in a system file?
Should I store my images in the database or folders?
Storing Images in DB - Yea or Nay?
I would also create a separate table for the documents, that way the search data/key fields for document retrieval will be more cache'able. The only time your database will need to touch the document table is during an insert or download.
I would recommend AGAINST storing the files in SQL. You are adding extra overhead when retrieving the files. IIS is really efficient at serving up files, but with SQL are the storage facility you now have introduced a bottle neck, as you now have to hop from your web server to your SQL Server and back to get the file.
When you store your files on the webserver, your process can determine the appropriate file based on the criteria you've listed, point to it and serve it. Document management systems such as Documentum and Alfresco store the files on a share, and this allows you great flexibility with respects to back up and and redundant storage.
I am sceptical storing large blobs in SQL, assuming that sql page size is 4k (off the nut).. it has to assemble fragment of the entire file in nK blocks when serving the file back to user .. I am not sure whether this is the case or not.
We ran in to a similar situation albeit in principle only. We needed a way by which documents stored to SharePoint could be accessed via a link on a web page. Since everything is project based with a unique project number the solution was to implement a common naming convention to the documents. s the web page is created server-side, the links are dynamically created. The code takes the base path to the SharePoint server and then adds the project number and specifics for the document.
Example:
[SharePoint Base Path][Project Numbe][Project Document Name]
[http://mysharepoint.mycompany.com/213990/213990_PC.pdf]
I am building an ASP.Net C# web application that will be using lots of sound files and image files. Considering performance, would it be best to store all files in SQL as image data type and retrieve from the database or store/archive the hard file on the server and store the path in sql? Im curious about the pros and cons - other than the obvious of storage space and manageability.
My current client is currently looking at the same options. There are a few tradeoffs to consider:
Storing as IMAGE data type:
You only need to backup your database rather than the DB and places on the file system
You don't have to worry about files being moved without the DB being updated with the new location or any other issues with hanging pointers to non-existent files
Storing as a file with a path in the DB:
Slightly faster access (we'll be quantifying this in the next few days)
Originally I thought that there would also be a problem with client-side caching of images. For example, when .NET gets the image out of the DB the client browser can't cache it - it looks like a new image every time. I then learned that unless you are giving users file-level access (a security no-no) you run into the same problem using direct file access.
From a performance perspective you should be better off storing the sounds/images as files and just keeping a reference to the location in the database. This will save you from having to transfer the data from the database to the web server and reconstitute the "file" via a handler whenever it is referenced. Of course, caching could help this but you'd still pay the penalty on each cache miss. This solution is also, for my money, somewhat less complicated in terms of the code that needs to be developed though you do have issues with collisions and some extra security setup (potentially) to do if you are enabling upload.
I'm building an ASP .NET web solution that will include a lot of pictures and hopefully a fair amount of traffic. I do really want to achieve performance.
Should I save the pictures in the Database or on the File system? And regardless the answer I'm more interested in why choosing a specific way.
Store the pictures on the file system and picture locations in the database.
Why? Because...
You will be able to serve the pictures as static files.
No database access or application code will be required to fetch the pictures.
The images could be served from a different server to improve performance.
It will reduce database bottleneck.
The database ultimately stores its data on the file system.
Images can be easily cached when stored on the file system.
In my recently developed projects, I stored images (and all kinds of binary documents) as image columns in database tables.
The advantage of having files stored in the database is obviously that you do not end up with unreferenced files on the harddisk if a record is deleted, since synchronization between database (= meta data) and harddisk (= file storage) is not built-in and has to be programmed manually.
Using today's technology, I suggest you store images in SQL Server 2008 FILESTREAM columns (at least that's what I am going to do with my next project), since they combine the advantage of storing data in database AND having large binaries in separate files (at least according to advertising ;) )
The adage has always been "Files in the filesystem, file metadata in the database"
Better to store files as files. Different databses handle Blob data differently, so if you have to migrate your back end you might get into trouble.
When serving the impages an < img src= to a file that already exists on the server is likely to be quicker than making a temporary file from the database field and pointing the < img tag to that.
I found this answer from googling your question and reading the comments at http://databases.aspfaq.com/database/should-i-store-images-in-the-database-or-the-filesystem.html
i usually like to have binary files in the database because :
data integrity : no unreferenced file, no path in the db without any file associated
data consistency : take a database dump and that's all. no "O i forgot to targz this data directory."
Storing images in the database adds a DB overhead to serve single images and makes it hard to offload to alternate storage (S3, Akami) if you grow to that level. Storing them in the database makes it much easier to move your app to a different server since it's only the DB that needs to move now.
Storing images on the disk makes it easy to offload to alternate storage, makes images static elements so you don't have to mess about with HTTP headers in your web app to make the images cacheable. The downside is if you ever move your app to a different server you need to remember to move the images too; something that's easily forgotten.
For web based applications, you're going to get better performance out of using the file system for storing your images. Doing so will allow you to easily implement caching of the images at multiple levels within your application. There are some advantages to storing images in a database, but most of the time those advantages come with client based applications.
Just to add some more to the already good answers so far. You can still get the benefits of caching from both the web level maybe and the database level if you go the route keeping you images in the database.
I think for the database you can achieve this by how you store the images with relation to the textual data associated with them and if you can the access to the images into a particular query so that the database can cache the query (just theory though so feel free to nuke me on that part).
With the web side, I would guess since you're question is tagged up with asp.net that you would go the route of using a http handler to serve up the images. Then you have all the benefits of the framework at your disposal and you can keep you domain logic cleaner with only having to pass the key to your image to the http handler.
Here is a step-by-step example (general approach, Spring implementation, Eclipse) of storing images in file system and holding their metadata in DB --
http://www.devmanuals.com/tutorials/java/spring/spring3/mvc/Spring3MVCImageUpload.html
Here is an example too -- http://www.journaldev.com/2573/spring-mvc-file-upload-example-tutorial-single-and-multiple-files
Also you can investigate a codebase of this project -- https://github.com/jdmr/fileUpload . Pay attention to this controller.
I want to use XML instead of SQLServer for a simple website.
Are their any good tutorials, code examples, and/or tools available to make a (prefer VB.NET) wrapper class to handle the basic list, insert, edit, and delete (CRUD) code?
The closest one I found was on a Telerik Trainer video/code for their Scheduler component where they used XML to handle the scheduling data in the demo. They created an ObjectDataSource class. Here is a LINK to that demo if anyone is interested.
[Reply to Esteban]
it would make deployment easier for clients that use godaddy where the database isn't in the app_data folder. also backing up those websites would be as simple as FTP the entire thing.
i have concerns about possible collisions on saving. especially if I add something as simple as a click counter to say a list of mp3 files visitors to the site can access.
In these days of SQL Server Express, I'd say there's really no reason for you not to use a database.
I know this doesn't really answer your question, but I'd hate to see you roll out code that will be a nightmare to maintain and scale.
Maybe you could tell us why you want to use XML files instead of a proper database.
It would make deployment easier for clients that use go-daddy where the database isn't in the app_data folder. also backing up those websites would be as simple as FTP the entire thing.
I have concerns about possible collisions on saving. especially if I add something as simple as a click counter to say a list of mp3 files visitors to the site can access.