If I can just add to Andrew's info....
1. Trying to use the LMCE SQL database to integrate HA hardware would be a fundamental misunderstanding of the LMCE architecture. LMCE is, at its heart, a messaging architecture. Doing what you suggest would mean that you were not really integrated with LMCE at all. There is a message hub called the DCERouter, all hardware and software modules (DCE Devices) create connections to that hub and communicate with each other through the DCE protocol. This is absolutely fundamental to LMCE. In this way, any DCE device (or software module) can trigger an action in any other DCE device, or group of DCE Devices by sending messages or events through the DCERouter. This is the way the automation is built. For instance - the environmental plugin (a software module on the Core server) can send messages to change the temperature of a room, this message goes to the DCERouter, which then passes that message on to an HA driver DCE device (another software module, say Hari's ZWave driver) which interprets the LMCE command for temperature change and sends the appropriate control signal to your HA hardware. Similarly, (and you can see the power of the system from this) when the Orbiter GUI DCE device sends the Play Media message to the media plugin, the media plugin sends a media stream object to the xine media player DCE device; at the same time a Start Media DCE event is generated and broadcast. The lighting plugin intercepts this event, and sends the appropriate DCE commands to any lighting in that room to dim by sending DCE commands to your HA hardware via the HA driver DCE device, again. [Thom, apologies, I realise this is not an accurate description, it was the best I could do, and was intended to be illustrative only
To achieve this integration through a SQL table not only would require you to build a new DCE driver device to handle the reception of DCE commands and events and write them into the SQL table, but would also be extremely indirect and inelegant! I would suggest you look at HA hardware that already has supported DCE device drivers such as ZWave. There is no reason to assume that if a system is powered off that the HA network becomes inoperable. On that point, the Core LMCE server needs to be on all the time for many reasons, maintaining and managing the LMCE network.
2. You can only choose Myth or VDR, not both, and they intregrate into LMCE as DCE device, as above. Squeeze stuff is very much a peripheral add on, not the main event! LMCE is a full and extremely sophisticated system in its own right, it certainly could not rely on the media database of squeeze.... squeeze is only actually installed if you have a squeeze device.
3. The text-to-speech system is just that, a simple DCE device that receives a piece of text and a location to speak it. It is a facility used by other DCE devices in the system to make announcements - they do the 'smarts' in contructing the message, T2S just speaks it. There is no reason why you can't build your own DCE device to provide your own smarts in constructing announcements, and then send the required DCE commands to the T2S module to speak it. But note that this is a complex system, you would need to understand the architecture and coding requirements first!