should I use short names?
52 views
Skip to first unread message
Yaron Naveh
Oct 5, 2012, 10:57:21 PM10/5/12
to ne...@googlegroups.com
Is it best practice to use short field names to save space? some db's like mongo encourage that. For example use fn instead of user_first_name.
Michael Hunger
Oct 5, 2012, 11:28:09 PM10/5/12
to ne...@googlegroups.com
No, they are stored in an index anyway and will be referred to by a property-id.
Michael
Am 06.10.2012 um 04:57 schrieb Yaron Naveh:
> Is it best practice to use short field names to save space? some db's like mongo encourage that. For example use fn instead of user_first_name.
>
> --
>
>
Michael
Am 06.10.2012 um 04:57 schrieb Yaron Naveh:
> Is it best practice to use short field names to save space? some db's like mongo encourage that. For example use fn instead of user_first_name.
>
>
>
Duane Nickull
Oct 6, 2012, 1:29:46 PM10/6/12
to ne...@googlegroups.com
Out of curiosity, if you had a DB where there are 100,000,000 nodes and
you can cut each node name from twenty characters to 2, would that not
save the persistence requirements by a factor, I considering the holistic
system?
With XML parsing, this did play a factor in large document instances
simply because the SAX parser could hand off SAX events quicker. The
factor was not huge but the in memory size of a resultant DOM and the DOM
based (akak XSLT, XPath, XQuery) queries did perform marginally better.
Just being curious and feel free to impose a beer fine at the next user
group meeting if I am off base.
;-)
Duane
***********************************
Technoracle Advanced Systems Inc.
Consulting and Contracting; Proven Results!
i. Neo4J, PDF, Java, LiveCycle ES, Flex, AIR, CQ5 & Mobile
b. http://technoracle.blogspot.com
t. @duanechaos
"Don't fear the Graph! Embrace Neo4J"
On 2012-10-06 5:28 AM, "Michael Hunger" <michael...@neotechnology.com>
wrote:
>--
>
>
you can cut each node name from twenty characters to 2, would that not
save the persistence requirements by a factor, I considering the holistic
system?
With XML parsing, this did play a factor in large document instances
simply because the SAX parser could hand off SAX events quicker. The
factor was not huge but the in memory size of a resultant DOM and the DOM
based (akak XSLT, XPath, XQuery) queries did perform marginally better.
Just being curious and feel free to impose a beer fine at the next user
group meeting if I am off base.
;-)
Duane
***********************************
Technoracle Advanced Systems Inc.
Consulting and Contracting; Proven Results!
i. Neo4J, PDF, Java, LiveCycle ES, Flex, AIR, CQ5 & Mobile
b. http://technoracle.blogspot.com
t. @duanechaos
"Don't fear the Graph! Embrace Neo4J"
On 2012-10-06 5:28 AM, "Michael Hunger" <michael...@neotechnology.com>
wrote:
>
>
Michael Hunger
Oct 6, 2012, 1:42:37 PM10/6/12
to ne...@googlegroups.com
He was asking about key names not values
And the keys are looked up from an index
Sent from mobile device
> --
>
>
And the keys are looked up from an index
Sent from mobile device
>
>
Duane Nickull
Oct 6, 2012, 1:53:30 PM10/6/12
to ne...@googlegroups.com
Ah - then ignore my question and order beers on my tab next meet up.
;-)
I misread. It reminds me of a joke whereby someone once claimed to
reduce the size of documents by using smaller fontsŠ..
ROTFL!
Duane
***********************************
Technoracle Advanced Systems Inc.
Consulting and Contracting; Proven Results!
i. Neo4J, PDF, Java, LiveCycle ES, Flex, AIR, CQ5 & Mobile
b. http://technoracle.blogspot.com
t. @duanechaos
"Don't fear the Graph! Embrace Neo4J"
On 2012-10-06 7:42 PM, "Michael Hunger"
>--
>
>
;-)
I misread. It reminds me of a joke whereby someone once claimed to
reduce the size of documents by using smaller fontsŠ..
ROTFL!
Duane
***********************************
Technoracle Advanced Systems Inc.
Consulting and Contracting; Proven Results!
i. Neo4J, PDF, Java, LiveCycle ES, Flex, AIR, CQ5 & Mobile
b. http://technoracle.blogspot.com
t. @duanechaos
"Don't fear the Graph! Embrace Neo4J"
>
>
Reply all
Reply to author
Forward
0 new messages