I'm trying to name a database attribute that might take the value "new" or "existing". What is an appropriate name? Something like "newity"? What is the relevant concept?

  • 2
    Does "New" really mean "Will be added in this version of the software", as opposed to "Existing = Already in the previous version"? If so, holding a version number could be a better data design; but in any case, "Status" would work. – Andrew Leach Jan 14 '13 at 15:33
  • 1
    How about "existence"? – Mr Lister Jan 14 '13 at 15:33
  • It also depends to a great extent on "new or existing what", so SO is a better place. They must have already invented the wheel. – Kris Jan 14 '13 at 15:40

An earlier answer suggests that the concept behind a database attribute with values “new” or “existing” is preexistence. This word refers to “The condition of existing prior to the current time”. By contrast, existence is “The state of being, existing, or occurring; beinghood”. You could use either term, depending on what you want to emphasize; but I suppose ideally the term should give equal play or emphasis to both of the possible values:

Preexistence, isNew or New?, newness give more emphasis to the “new” aspect, and less to “existing”.
Existence, isExtant or Extant?, extancy more-emphasize “existing”.
Vintage (“The year or place in which something is produced”) or revision (eg a version number), and previously-mentioned status (“A situation or state of affairs”) seem neutral, but may be too general or may have meanings you don't want.

Note, the obsolete term extancy means “The state of being extant; existence”. (Adjective extant means currently existing.) Even though extancy is obsolete, it might work as a label for the field.

  • Extancy is perfect. "Existence status". – jl6 Jan 14 '13 at 21:54

As an ex-database person myself, I racked my brain (gently, no injuries yet) to remember how I would have handled this situation. Depending on the naming convention, you may need to add or remove capitals, add underscores, etc., but here are my suggestions:

StatusID (keyed to a separate table; good suggestion by Andwer Leach)
CreationDate (or similar date-time field)
IsLatest (if version tracking)

It depends on your goal. If new items just need processing to flip from new to not-new status, use a boolean or similar two-state type of field and flip as indicated. Naming conventions for such types often begin with "is", to indicate a two-state value. If you have multiple statuses, of which "new" is only one (either now or anticipated-- planning ahead is never a bad idea with a database) then use statuses and make "new" one of them. If you just need to create some sort of view of the recent additions, track by date/time. And, of course, if you're doing version tracking, something like IsLatest might be appropriate to indicate the latest version of an item. Finally, don't forget to check naming conventions in use wherever the database is being implemented, or evident elsewhere within the same system.


I think what you're looking for is preexistence. This deals with the temporal nature of the existence — in other words, instead of just recording whether or not something exists, it records whether something existed before a particular event or moment in time.

Another option (as mentioned in the comments to your question) is "status" but that's a bit generic.

  • I'm not downvoting your answer, but would note that 1) nobody would ever name a database field "pre-existence" or any variation thereof, 2) the correct naming, if it were chosen, would be "is pre-existing" with a value indicating truth or falsity for a particular item, and 3) status tracking is common in databases, especially if more statuses are to be added later-- it's not "generic" in a bad way, but often just proper design. – Iucounu Jan 14 '13 at 16:18
  • @lucounu What I meant by "generic" is that there are lots of different statuses you may wish to record. "New/existing" is one form of status. "Live/archived" could be another. You might want to capture many different "status" type data in different fields in one record. – Waggers Jan 15 '13 at 11:43
  • I know what you meant, but it's not a disadvantage of using a term like "status" (or, more often, "status id" with a key to a separate table). It's common to see such things when one has more than a boolean type of field, i.e. one which has or may come to have more than two discrete possible values. You're right that more than one field might indicate a status on the same record, but that would mainly occur when the record participated in more than one well-defined but separate processes. – Iucounu Jan 15 '13 at 14:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.