SharePoint has some similarities with databases. For example, like a database, it is used for storing and archiving files, and it can validate data that a user enters. Also, SharePoint utilizes the concept of document libraries, lists, columns and data types, which makes a repository look like a typical database structure.
However, that’s where the resemblance ends, as databases have more complex relationships between its records, columns and tables than SharePoint can ever support. One more thing that confuses users is that Microsoft SQL Server supports all content stored in SharePoint. And Microsoft SQL Server is actually a relational database management system.
Having 12-year experience in working with SharePoint, we can say with confidence that this platform is powerful when used for document management but it’s quite inept as database software. Below we provide the main reasons why SharePoint can’t serve as a full-fledged database.
Why is SharePoint no good as a database?
SharePoint can’t offer the same functionality as a database. Specifically, SharePoint lacks a number of basic database features that are responsible for collecting, storing, retrieving, sorting, graphing, and manipulating data in various ways. Here are some of the examples:
No database-like data organization
SharePoint doesn’t support complex data relationships typical of relational databases, such as:
- One-to-one. A record in one database table is related to only one record in another table. For example, a single employee can be an author of multiple documents, but a single document can be linked only to one employee. This type is rare, it’s usually used for dividing the table into multiple columns or isolating parts of a table into different sections for better data security.
- One-to-many. A record in one table relates to one or to many records in the second table. For example, one book may relate to many authors and categories.
- Many-to-many. Each record in two tables can relate to any number of records (or no records) in the other table. This kind of relationship requires at least three tables (e.g. books, authors, and publishers).
These relationships are impossible in SharePoint. SharePoint list item IDs can’t be used to define relationships between different list items, just unlike primary and foreign keys, specific database identifiers, can do by linking tables.
No large volume of items and binary data
Unlike a database, SharePoint can’t handle many items. Even the SharePoint product team advises limiting the number of items in a list to 2,000 for each list container (the root of the list and any folders in the list), otherwise, the list performance significantly decreases. Also, SharePoint allows storing binary data only in the form of attachments to lists, while most modern databases fully support storing large binary files like video files, large volumes of text, images and more.
No transaction rollback
SharePoint doesn’t support the rollback of transactions. This means that in SharePoint environment, you can’t roll back changes if, for example, two changes are required to go together and the second change fails.
Although SharePoint rests on a database management system and has some similar functionality, the platform itself is not a database. If all you need is just structured and secure storage for several thousands of documents, SharePoint can easily meet your needs. But if you need a full-fledged database with an ability to store millions of files of multiple types with an ability to manage complex relationships between items, SharePoint is not your best choice.