Freigeben über

Is placing the assembly in the database next?

  • Artikel

In SAP implementations, the ABAP code that performs the functions of various business processes is stored in the database, or so I'm told.  I was having a discussion a few days back with an architect who works closely with SAP, and has for years.  His take: now that SQL Server Yukon can call .net code easily, why not start placing byte code directly into the database.

The advantages are interesting:  the deployment of a system is a matter of placing data into a database.  Version control takes on a whole new meaning for folks not used to this concept.  You can create a utility for placing a version into production, and if there is a problem, rolling back to a prior version is a matter of flagging records in the database as "inactive" or deleting them.  Database backups are also system backups.  Deployment requires data movement utilities, but can happen to multiple locations easily.

This doesn't mean that the assemblies have to run on the database server.  SAP uses application servers extensively.  The code stored in the database could be installed to the app server and could run there without difficulty.  Kind of "database driven one click deployment".

It's an interesting idea.  I'm sure that theres an article in there for someone who wants to write it up for one of the dev magazines: how to put your assemblies into SQL Server and call them.

Comments

  • Anonymous
    September 21, 2005
    I once had a hair-brained idea such as this. The idea was to store uncompiled code in XML and utilizing reflection to dynamically compile the code when required. Nothing really came of the idea (well... it does sound a lot like XAML). Nonetheless I do think there are some benefits to storing all business logic in a centralized location. A database can be accessed by TCP/IP to pull the code needed to run something much like windows file sharing can be used to pull XML from a shared folder. Essentially its a smartclient for developers as well as users...

    Regards,

    Gabe
  • Anonymous
    October 10, 2005
    Strangely I have been thinking about this lately. What would be really cool would be the ability to store objects 'whole' in a database. I know OO databases exist, but they look a bit clunky and it would be great to be able to store the properties AND the methods.

    This starts to bring in versioning issues, but I love the idea of being able to just instantiate an object straight from the database (or create a new one), call it's methods and then just save it away.

    I guess the methods would be seperated from the data and these could be changed and versioned appropriately (and backed out etc as you suggest).

    Relationships between objects could also be preserved and the class would define these.