How do you defend your Alpha implementation when your company calls for a major Microsoft SharePoint integration?

Well, you can come back to the Alpha blog and reference the following article!

"Comparing SharePoint with Alpha" was written by one of our Alphaholics when he was asked to evaluate the possible decision of a Microsoft SharePoint migration. After months of research, he presented the article below to the rest of the company.

Microsoft SharePoint integration is something we see happening more and more in big corporations. But like building a house, a company needs many different tools to be built successfully, so SharePoint might not be the one-size-fits-all solution that it appears to be.

The article pasted below is exactly how it was sent to me -- we haven't touched a thing. Give it a read if you're in the mood for a technical, in-depth analysis.

COMPARING SHAREPOINT WITH ALPHA

I was asked by Bill Brush to evaluate the possibility of using SharePoint as a migration direction from Alpha DBMS which we’ve been using for years.

An important decision in the design a user application is whether to store information in lists or in a database like Alpha which is how NET manages engineering information. The version of Alpha we have is almost 6 years old and does not run well on the new MS OS Windows 7 so there is a compelling reason to examine how to proceed in the very near future.

We are heavily leveraged with legacy applications using the Alpha Application Developer. However, these applications work well and it is likely they can be ported to the newer version of Alpha. The cost for the new product is about $1500. Development time in person-hours is unknown but not daunting. One of the issues regarding this is the lack of planning to implement an upgrade so we’re a bit behind the curve in this aspect of moving forward.

SharePoint has been suggested as a replacement for the current database infrastructure. It consists of lists represented by rows and columns that store data in a similar fashion to a traditional relational database management system such as SQL Server. However, a benefit of lists is that SharePoint includes Web Parts that provide simple methods for managing the data. If the data is stored in a database, it requires custom user interface components to access and manipulate it. These have already been developed and have worked well so this is not a disadvantage.

There are major advantages to storing data inside of a database. One is the availability of all the ACID (Atomic, Consistent, Isolated and Durable) properties of transactions. If NET logic requires transactions (which it does), storing data in a database is preferable to using lists. Also, SharePoint lists are meant to store simple data structures. NET requires a complex data model with intricate relationships, so Alpha is more appropriate. Most Sharepoint application data is relatively simple and does not use transactions which is required with our present applications.

In general, reading and writing to a custom database provides an overall performance advantage. Although SharePoint has made significant strides in its performance, there is still a certain amount of overhead involved in processing lists. One recommendation by some SharePoint product teams is to limit the number of items in a list to 2,000 for each list container. (A container is the root of the list and any folders in the list.) You may be able to manage larger lists by using views that are filtered so that no single view contains more than 2,000 items. Another way to circumvent this performance degradation is to write custom interfaces to manage and retrieve the data. (It is important to note that the 2,000 item threshold has more to do with HTML rendering performance than with the underlying performance of lists as a storage mechanism.) A considerable amount of training and would be required for NET personnel to achieve this and it is daunting.

Lists are great for flat information with changing content, especially when attached to unstructured documents. At least in the current version, lists are not substitutes for databases and shouldn’t be considered so.

There is no really good way for surfacing bi-directionally data from a database into SharePoint – the business data catalogue works only in read only mode and does not allow for updates back to the underlying data store.

Here’s some other points:

• Primary and foreign keys: one of the most basic concepts in a database is the enforcement of a unique identifier (either system generated or user supplied) that can identify a record and link across table in parent child relationships.

• Transactions: if two changes are required to go together and the second change fails you want the first change to be undone (rolled back).

• SQL language: complex queries can be written in code using a standard language. Queries can be saved and repurposed.

• Stored procedures: database programmers can write complex routines that can be called as reusable code blocks.

• Indexing and query optimization: used to improve performance, indexing allows the database designer to pre-index specific fields that are frequently used in queries to improve performance. In addition, most databases have optimization engines that, based on what you are trying to fetch, will optimize how the data is retrieved.

• Large data and binary fields: most modern databases allow you to store large binary files such as video files, large volumes of text, images, etc. in the database. SharePoint can be made to store large files as documents but you only get one per record and a generic binary object. Alpha has not only images but unlimited sized memo fields which we use extensively.

• Access outside of SharePoint: lists are accessible outside of SharePoint but only through XML or programming interfaces. Lists are not great data stores to be used for line of business applications written independently of SharePoint, because the integration is relatively poor in comparison to running a SQL query on a database.

• Cascading deletes: if a parent record is deleted, its children should also be deleted. In most databases, this can be configured to happen automatically or else reject the delete of the parent until the children are deleted first. This eliminates the risk of orphan child records.

• These features are considered basic in databases – they have been around for decades and even the most primitive databases have most of these features. Alpha has them all.

With these considerations, Sharepoint would not be a good choice and would require considerable development and training time and is not recommended. Upgrading to the latest version of Alpha is my suggestion.

Has your company suggested a Microsoft SharePoint integration? What did you think? Tell us in a comment.