Business in VR: Interfacing a Sales Database with a World
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:
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.