<p>A field is a field, no matter where you are using it. It doesn't matter to Craft whether you attach your field to a Global Set or a Section (or Users or Assets)... All fields are treated equally.</p>

<p>Your fields can be shared between Element Types, and often are.</p>

CC BY-SA 3.0
2014-11-26T10:43:56.333Z
Using an entire column in the content table just for 1 global field seems like overkill to me just to add one site-wide preference. I guess I am looking for an alternative to "Low Variables".
Lea Hayes
CC BY-SA 3.0
2014-11-26T18:25:40.010Z
Globals actually _are_ a good alternative to Low Variables. No offense, but you may be overthinking the internal data structure that Craft is using to store that field data. I'd recommend reading [this question & answer](http://craftcms.stackexchange.com/a/4884/45) for a little more clarity on why Craft stores field data the way it does. It's vastly more efficient for Craft to use the same data structure and code to store Global values as it does with any other field, and totally worth the tradeoff of an extra database column.
Lindsey D
CC BY-SA 3.0
2014-11-26T18:29:59.130Z
I think the key thing to understand here is the concept of [Element Types](http://buildwithcraft.com/docs/plugins/working-with-elements). Craft prides itself in treating all element types as "first-class citizens"... this includes Assets, Users, Matrix Blocks, etc. It's one of the reasons (arguably the _biggest_ reason) why Craft is so much better architected than all of its competitors.
Lindsey D
CC BY-SA 3.0
2014-11-26T07:10:18.380Z
2014-11-26T07:10:18.380Z
Lindsey D
<p>I understand the rationale of adding one column per custom field to the <code>craft_content</code> table in the database; but why would this happen for fields that are only used once globally?</p>

<p>Is there a way to define global fields without adding to the entire content table?</p>

<p>Perhaps a better option would be to define a single "Options" matrix field which can be used anywhere, and then use that to store zero-or-more options?</p>

<field><globals>
Global-only fields adding columns to content table?
# Global-only fields adding columns to content table?

(Asked by: username_0 on 2014-11-26)

I understand the rationale of adding one column per custom field to the `craft_content` table in the database; but why would this happen for fields that are only used once globally?

Is there a way to define global fields without adding to the entire content table?

Perhaps a better option would be to define a single "Options" matrix field which can be used anywhere, and then use that to store zero-or-more options?

**Tags:** field, globals


---

## 1 answers

### Answer by username_1 on 2014-11-26. Score: 1

A field is a field, no matter where you are using it. It doesn't matter to Craft whether you attach your field to a Global Set or a Section (or Users or Assets)... All fields are treated equally.

Your fields can be shared between Element Types, and often are.

> **Comments:**
> **username_0**: Using an entire column in the content table just for 1 global field seems like overkill to me just to add one site-wide preference. I guess I am looking for an alternative to "Low Variables".  
> **username_1**: Globals actually _are_ a good alternative to Low Variables. No offense, but you may be overthinking the internal data structure that Craft is using to store that field data. I'd recommend reading [this question & answer](http://craftcms.stackexchange.com/a/4884/45) for a little more clarity on why Craft stores field data the way it does. It's vastly more efficient for Craft to use the same data structure and code to store Global values as it does with any other field, and totally worth the tradeoff of an extra database column.  
> **username_1**: I think the key thing to understand here is the concept of [Element Types](http://buildwithcraft.com/docs/plugins/working-with-elements). Craft prides itself in treating all element types as "first-class citizens"... this includes Assets, Users, Matrix Blocks, etc. It's one of the reasons (arguably the _biggest_ reason) why Craft is so much better architected than all of its competitors.  

---

