![]() |
Variable Pointing To a Class Address?
I'm trying to write an sql parsing tool for specific purposes. I'm going to run all the sql statements through mysql but any create statement needs to update the table if there are new fields. So it doubles as an alter statement.
The problem I'm having is a simple one but I'm wonder how this could be possible in PHP. Each statement I parse out will be called a Command and extend the SQLCommand super class. I'm going to determine what command it's using by looping through each word of a command, adding it to a string where I try to match it to an associative array. PHP Code:
PHP Code:
PHP Code:
$CommandCls &= $knownCommands[$commandStr]; $Command = new *$CommandCls($commandStr); My pointers might be off. |
Neither of those will work in PHP. The first is probably supposed to be =& which can be done in PHP, but you cannot dereference with * as that syntax isn't available in PHP (or more accurately, you cannot get the pointer directly in PHP, you can only retrieve the value, or assign the pointer through direct assignments in PHP).
PHP uses object instance pointers, which are *kinda* like pointers. They're not the same though. For most typical work, these are *mostly* synonymous in PHP 5 (php 4 is a different story): PHP Code:
Now this all said, for what reason do you need to issue an alter command? Typically speaking, with the exception of installation process, you shouldn't need to ever issue a CREATE, DROP or ALTER SQL command in a project. |
I got it figured out...
PHP Code:
Quote:
|
That doesn't look like your original question at all. It will work though, assuming that's what you need to do.
PHP is a string based language. Strings are a primitive datatype as the union includes the char* within the zval. As for large systems, no I guess not. I'm in a medium scale business with about 40TB of database usage and a little over 1300 servers many of which act together of course. I've only issued one table alteration in the past five years, and that was on a third party vendor software which chose a datatype too small to represent a number of bytes. The development team likely runs a lot of DDS statements within their code at runtime, but not a single one of those would make it into the production systems. |
Quote:
PHP Code:
Quote:
Possibly more dynamic with a key-value table for each element? I'm only speculating but assuming something like this (if your system even requires to be this dynamic)- You'd probably have a performance boost with actual tables instead of this setup and you wouldn't need to spend so much on servers. Ours is different however (Imagine). Not only does the codebase need to be shared across each server but tables are added and frequently changed while we make partnerships that require these changes/additions. Quote:
|
Yep, I'm not going to lie. I didn't read through your code at all since I assumed you have a normalization issue.
If you have a normalized database, and you are still regularly issuing DDS', than that's fine. I can't see a reason for it even across platform; all that matters is that its normalized. But to me, constantly altering the structure does reek of a normalization issue. |
| All times are GMT +1. The time now is 06:31 AM. |
Powered by vBulletin®
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.