maria-discuss team mailing list archive

[Roberto Spadim <roberto@xxxxxxxxxxxxx>]

2015-01-29 11:57 GMT-02:00 Tom Worster <fsb@xxxxxxxxxx>:

> Hi Oleksandr,
>
> I'm going to stop bitching about Maria now. My needs are in fact met by
> the current dyncol functions:
>
> - It's not so hard to write methods that generate CREATE_COLUMN()
> expressions from a general data structure.
>
> - COLUMN_JSON() is just fine for all my reading purposes. I see no need
> for a naked COLUMN_GET() in a SELECT.
>

take care, when you return more data than you really need, you use more
network, memory, cpu, cache, buffers...
something like SELECT * FROM table, when you only need SELECT column_a FROM
table
with big system or small hardware you may have problems



>
> - Generating COLUMN_GET() expressions for use in queries ends up being a
> regex replace with some packaging.
>
take care with the size of final query... for example
SELECT COLUMN_GET(),COLUMN_GET(),COLUMN_GET()..... 256 times FROM table

if your network is a problem, maybe is better SELECT column FROM table, and
execute the column_get at client side, this reduce network, and memory used
at client and server side with the SQL string (query)



> - As I said in the email to Frederico this morning, indexes are not
> unimportant but a lot of apps can live without and many will be fine.


> When I wrote my original email, that list of seven concerns were factors
> in my vague worry that dyncols are going to remain ignored and unloved.
>
i like and use them =] but i don't love dynamic column without index, today
i execute workarounds to solve this


> That original email is adequately answered and I have the information I
> need.
>
nice =]


>
> Tom