All of this information is freely available in a few whitepapers that are a part of VMware vCloud Architecture ToolKit (vCAT) 2.0. These sets of documents are very in-depth and offer a great learning experience for anyone looking into vCloud Director. Note: I'm not discovering anything new, I am just merely pointing out some of the caveats and thought considerations that may be brought up.
vCloud Director extends the capabilities of the vSphere layer and focuses on delivering an IaaS model where by consumers can request resources from a cloud environment. vCloud Director also packages the vCloud API along with it that allows custom applications to be written so you can talk to a vCloud instance.
Let's dive into the first standout feature of vCloud 1.5: SQL Database support. Originally, vCloud Director was only supported on Oracle databases, which may have been a big influence into it's lack of early adoption. I have written an article called Installing vCloud Director 1.5 With SQL Server 2008 that details the steps to install vCloud Director using SQL Server. Some design considerations to take into account now is your SQL Database VM Sizing and perhaps having multiple SQL VMs. There are many components in a vCloud Design that utilize a SQL database: vCloud Director, vCenter(s), VUM(s), Chargeback(s), vCenter Orchestrator, and more. The size of your VM is now greatly effected if you have all these databases living on a single VM. Of course it can be done, but there is also the possibility to split it out into multiple VMs. A constraint to keep in mind for running vCloud on SQL or Oracle is cross-compatibility if you ever decide to switch. Moving from Oracle to SQL isn't an easy process as indicated in a 167 page document. VMware recommends a 4vCPU VM, 16GB of RAM and 100GB of Storage.