Re: string to array [message #177267 is a reply to message #177266] |
Fri, 02 March 2012 18:38 |
M. Strobel
Messages: 386 Registered: December 2011
Karma:
|
Senior Member |
|
|
Am 02.03.2012 19:09, schrieb Jerry Stuckle:
> On 3/2/2012 12:03 PM, M. Strobel wrote:
>> Am 02.03.2012 15:46, schrieb Jerry Stuckle:
>>> On 3/2/2012 8:17 AM, M. Strobel wrote:
>>>> Hi,
>>>>
>>>> I am just testing with hstore in postgresql, this is a datatype providing a
>>>> key-value-store in one column
>>>> (http://www.postgresql.org/docs/9.1/static/hstore.html).
>>>>
>>>> The php question is:
>>>>
>>>> A select from the table looks like this:
>>>>
>>>> trans1=> select * from testh;
>>>> Tabelle testh
>>>> n | h
>>>> ---------+-------------------------------------------------------------
>>>> Michael | "age"=>"89", "weight"=>"91", "haircolor"=>"braun"
>>>> Peter | "weight"=>"82", "haircolor"=>"rot", "has spaces"=>"is true"
>>>> (2 Zeilen)
>>>>
>>>> And a select gives me the h column back as a string:
>>>>
>>>> array(2) {
>>>> ["n"]=>
>>>> string(5) "Peter"
>>>> ["h"]=>
>>>> string(59) ""weight"=>"82", "haircolor"=>"rot", "has spaces"=>"is true""
>>>>
>>>> This looks like php source code. How could I just eval it to get a php array?
>>>>
>>>> /Str.
>>>
>>> Don't use it. It's a bad design and fails normalization (one value in a column). It
>>> also s not easily searchable nor can you modify values easily. You also don't run
>>> into problems like this.
>>>
>>> A much better way is to have a separate table with key and value columns and a
>>> reference column.
>>
>> "bad design" and "fails normalization" is generally true, but I am just fed up with
>> yet another properties table. hstore is made for it, it is searchable and changeable,
>> but nonstandard.
>>
>> I think it would be an elegant solution if I would not have to read in the properties
>> separately, but the whole class in one take, and "explode" this string into an array.
>>
>> /Str
>>
>
> Property tables are quite useful. And how much of your design are you going to have
> to change if you do need to go to another database like Oracle, SQL Server, DB2 or
> even MySQL?
>
> I do not like being tied to a single database. I've seen too many disasters that way.
>
My design is: put as much application functionality as possible in the database, then
have the option to write different front ends without having to recode all the logic.
Now I am coding triggers and functions in pltcl (yes, sending mail in pltclu from the
database, and deleting files). No option to change that.
In the last project I took over I had to rewrite important parts of a web application
only to get a ftp and sftp job entry interface.
This is the disaster I am trying to avoid.
Well, now it turns out that my php classes representing entities like users,
companies, orders, are completely independent from the web server. This is very
valuable as well, and not very difficult to do. I could use them for batch job entry,
but not for coding a fat client... (hm, you call it rich client)
So the database is there to stay.
/Str.
|
|
|