Richard Huxton wrote:
I imagine it's cheaper disk & dump wise to do the array thing in this and
some other similar usages, and therefore it would be nice to have a
non-ugly usage pattern.
Don't imagine, test. And then factor in the cost of fiddling around with
arrays when you need to acces
Marcus Engene wrote:
> So with memcached I care less about saving a few mS in select latency
> and more about postponing other approaching problems like having the
> dbdump manageble. Right now it's a 100MB gzipped dump, which is very
> manageable, so where it's possible I'd like to keep the data c
Richard Huxton wrote:
Marcus Engene wrote:
Hi List,
I have the might_like table that contains products a user might like if
he likes the present one (item).
CREATE TABLE might_like
(
item INTEGER NOT NULL
,created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
Marcus Engene wrote:
> Hi List,
>
> I have the might_like table that contains products a user might like if
> he likes the present one (item).
>
> CREATE TABLE might_like
> (
> item INTEGER NOT NULL
> ,created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL
>
just as a little advice, I would actually use joins - for performance
reasons. 'where in' seems to be rather slow, especially if you use it on
large sets of data.
Hi List,
I have the might_like table that contains products a user might like if
he likes the present one (item).
CREATE TABLE might_like
(
item INTEGER NOT NULL
,created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL
,child INTEGER N
