Occasionally we have been asked how Qrimp compares to Microsoft Sharepoint. I won't discuss costs here, but I will say that Qrimp is sold per user license for the Qrimp platform, not by the number of users within Active Directory. This can be a significant cost savings when only a portion of your organization will be using Qrimp.
First, Sharepoint is a very extensible system. It integrates with a lot of tools from Microsoft, including Windows Workflow Foundation. This is a nice capability, but these are heavily oriented toward developers. To customize Sharepoint capabilities, you'll need a license for Visual Studio.
Qrimp is designed to be fully extensible from the web browser. There is no need to buy Visual Studio or other tools from Microsoft unless you run Qrimp on your own servers, in which case you'll need SQL Server. You'll need SQL Server for Sharepoint as well.
From the front end, the interface is much easier to use. You can add new lists to Sharepoint from within the web interface, but it is fairly complicated. I recently asked a Sharepoint guru how difficult it is to teach business users how to extend the Sharepoint capabilities and he said it isn't very easy. We've taught users who previously didn't know what a database was how to use Qrimp. If a user can understand a spreadsheet, they can probably understand what Qrimp is.
The Database Architecture
The significant difference between Sharepoint and Qrimp is that accessing the Sharepoint database directly is almost universally forbidden. Microsoft does not support directly modifying the Sharepoint database.
When I asked the aforementioned Sharepoint Guru what he thought about the issue, he said: "NEVER NEVER TOUCH THE DATABASE DIRECTLY!" A Sharepoint Thoughts post
Whatever you do, do NOT PERFORM DIRECT EDITS TO THE SHAREPOINT DATABASE.
* Do NOT manually update records
* Do NOT manually insert records
* Do NOT manually delete records
* Do NOT MODIFY SHAREPOINT DATA!!!
The reason is because the database architecture used to store the data within the Sharepoint system is much more complex than that revealed by the API to the developer. To access the data in the Sharepoint repository, you must go through the Sharepoint API. The API conceals the underlying data model from the end user and this data model could change with service packs.
Qrimp on the other hand builds a standard database architecture for your data. Tables are tables. If you view your table in grid view, that's what your table will look like if you accessed the database directly. If you update a record in your table with an SQL Query and then view that record from the web interface, the record will be updated. No harm done. One caveat is if you have versioning enabled on the table, the edit will not be stored, but your database will not be corrupt. Similarly, you can delete records or insert new records as well.
If you run Qrimp within your firewall, you can use bulk import tools to bring in as many records as you want into your Qrimp database and start using your system right away. There are some rules to how Qrimp stores information in the database to be aware of. Each table has an ID field that is an Integer Identity that is the Primary Key. The CreateDate and CreateId fields have special meaning for auditing. The rest is fair game.
The differences then, between Sharepoint and Qrimp is that Qrimp allows you to pay for only the users who use the system. Sharepoint is more extensible because you can use tools like WWF and Visual Studio to write any code you want -- but you have to code it. The final difference is that with Qrimp, your data is your data. You don't have to go through Qrimp to access it. If at some point in the future, you realize you need a custom process to access your Qrimp database and make changes and retrieve data, you can do that.
Qrimp is more flexible in this way. With Sharepoint, you are locked into using Sharepoint as the interface to your data. With Qrimp, you can pull your data out or access the existing Qrimp Database without any modification. Qrimp creates very nice standard data models for your data. Most DBA's will quickly recognize the models Qrimp builds for One-to-Many and Many-to-Many relationships.
If you have any questions about this, please don't hesitate to contact us