When setting up a product database, as a business, and linking it in to a commercial virtual environment run by another company, you have many issues to consider that may not be immediately apparent.

Platforms such as Second Life, Activeworlds, Andromeda and others have their own internalised database structure, which they use for generating the world around both you and your customers. For most businesses, the desire is along the lines of placing their own products or services in a 3D virtual environment, such that customers browse through and ultimately purchase via VR.

Its partially 'cool' factor, partially good business sense, and allows for automation of sales, on a scale not possible with a physical store, whilst at the same time preserving the sense of product you do not get with lists of goods on a standard website.

However, if you are using a third party created virtual environment rather than one you have created internally within your own organisation, hosted on your own internal servers - which most businesses have neither the resources nor inclination to do, then there are some safety issues to take into consideration.

The only way you can tie actual products together with 3D product representations within a third party virtual environment, is through whichever scripting method the environment uses to allow you to access external entities. For some its bot programs, for others it is scripting languages. However, whichever it is, do not just hook the virtual world up to your database system. That has some fundamental flaws in approach:

• You effectively open up your internal product database to curious minds with itchy fingers from all over the internet, as in order to interface properly, you are forced to imbed usernames, and passwords for your database into the world scripts.
  
  
• By the very nature of a commerce transaction, the username used would have to have write access to your database. This is a very bad thing to puvlicly give out.
  
  
• You likewise expose how your database is internally structured to the outside world, in the form of the scripts you run and how they pull information from the database. Again, this exposes potential security flaws to the outside world. You may or may not actually have security flaws in the database design itself, but letting every kiddie hacker who stumbles across your 3D shop explore it, is perhaps not the best way of finding out.
  
  
• Commercial VR scripting is not secure. No matter how much it claims to be.
  
  
• If the VR world goes offline partway through a transaction, the transaction ends, with no possible recourse except rollback, and that would likely have to be manual. Not a great way to inspire repeat customer loyalty
  
  
• Payment information from the customer would be sent by the VR environment. Most send information in the chat box as open text. Not the way to treat your customer's credit card details.

Instead, a far better and safer approach is to use the scripting system to talk to a flatfile, or intermediary database on your server, that serves no other purpose than taking the product information, customer IP if available, and session info from the virtual environment. Session info so you can track other products bought by the same customer that day.

Then, have a second set of scripts on your webserver, visible to no-one in the outside world, and take the information from the intermediary database and put it in your main one. Security problems for you are solved - at best, a hacker could affect the intermediary database, and all that is is a list of what products are being processed at that particular time. No payment info, no personal details of clients. Purge the data from it at the end of each transaction.

For customer credit information, have a second script in the VR environment, that simply calls a script on your sever. The script on your server loads a page under your control, for the customer to enter payment details under your SSL control, and with the normal payment assurances.

To recap

• Do not allow your product database to connect to the world directly. Use a script or bot in the virtual world, that calls a script on your web server. The script that is entirely on your web server should be the only one that accesses your main database in any way.
  
  
• Store a copy of details relevant only to that order, in a separate storage medium on your site, so that if the VE world does go down during the process, you can continue as if it had not. Delete that information the moment the transaction has completed.
  
  
• Do not pass any personally identifiable information of financial info through the in-world system. Call up your own scripts to do that using embedded web windows.