Sharepoint 2007 to use Sql Server database, Pros and Cons

Our IT manager is asking my help on deciding on wh开发者_如何学Cich would be the best to save the data. Is it in sharepoint or sql server.

On my side I don't know much about saving data on sharepoint server, how does it work, how fast, how secured, etc. I even have a doubt if sharepoint is capable of complex database design. As far as I know, sharepoint is not a database server that's why I have this doubts.

So obviously I would say Sql Server would be my prefered storage and also because Sql server is known to me for a long time already. Considering my 3 weeks exposure on sharepoint vs. 7 years on Sql Server. I don't have the enough experience to witness the strength of Sharepoint for me to decide on what to do. So to be fair on sharepoint I would like to ask you guys out there who are more experienced on this.

My questions:

1.) Does sharepoint have the ability to store data?

2.) If sharepoint can store data, what are the pros and cons?

3.) Can it cover a complex design such as relational database design like sql server does?

4.) If you where to develop a sharepoint project, would you choose sql server as the backend?

Thanks in advance!

It obviously depends on the application, and complexity of it, who the client or audience is, and how you want to deploy it.

Here are my answers to your questions:

1. Yes
2. Pros:
   It provides a UI for updating data.
   Cons:
   Creating relational structures will be complicated.
   Think custom lookup lists, associated with other custom lists.
3. Yes, but I wouldn't try it.
4. SQL Server, but this depends on the project and 
   isn't an entirely technical decision.

Personally, I think given your skillset, you should use SQL Server, if your manager has said it's up to you.

SharePoint itself is built on top SQL Server and ASP.NET.

1. Yes. You can create a custom list (basically similar to table structure), you can store document along with its metadata. You can store web pages if you are using it as your publishing (CMS) platform.
2. It's not supposed be a relational engine like SQL Server. Pro: versioning, workflow, for most cases, UI is there to support data input / editing. Con: Limitation of the UI w/ large amount of data.
3. To some degree you can relate one list to another field in a different list / document metadata.
4. See what I said before point 1.

SharePoint offers its own database layer built on top of SQL Server. A complex object model is provided, and the SQL language API not available. Acsess is by API, REST, and UI List Webparts with views; NOT SQL and the database is not accessible except through interfaces. Deep inside data stored in Entity-Attribute-Value triples (specifically: site, web, list, item, state, field, value) such that each value goes into its own record. This is strickly non-tablular. Maintains a dynamic end-user populated Metadata dictionary. As a non-relational layer above a DB is offers inheritance, multi-type list, hierarchies, taxonomies, versioning, check in/out and other advanced features missing from a relational model. Documents may be attached to a list. Extensive use of GUIDS for identifiers, but this causes problems when moving partial related data between systems. No referential integrity. No joining of database tables or lists. Filtering is more limited than in SQL. No concept of a schema. Parts of SharePoint break when restoring from a backup or when published to a separate site. Rolling new features and data from development to production is problematic and sometimes breaks. Hope this helps.

Sharepoint is obviously not a Database Server but somehow it works on some ways.

1.)Yes

2.)You can but not as complicated as Sql Server does.

Pros: It's the interfaces the gives sharepoint the edge, UI grants the user a friendlier way of inputting data.

Cons:Just like what I've said complicated database design is not easy to do.

3.) 100% Yes

4.) I would prefer Sharepoint if the application doesn't need complex design on data. Definitely Sql Server for enterprise type of application.