2015-01-29 11:57 GMT-02:00 Tom Worster <fsb@thefsb.org>:
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