| Re: string to array [message #177268 is a reply to message #177267] |
Fri, 02 March 2012 19:49   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 3/2/2012 1:38 PM, M. Strobel wrote:
> 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.
>
My point being not the server - but the database. What happens if you
have to go to a different database?
Oh well, it will be your client who suffers, not mine.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]