0

I have the following entities in database that have a corresponding table "entityN_statuses" associated with each of them:

  * products
  * refunds
  * payments
  * users
  * etc...

The "_statuses" tables have the identical structure: (id, name (unique), description)

Each entity table has "status_name" as a foreign key.

An issue is naming the statuses in each of the "_statuses" table.

This isn't what I want:

  * refund_statuses: (new, being_refunded, refunded_successfully, canceled)
  * payment_statuses: (pending, in_progress, paid_partially, failed, voided, paid_completely)
  * products: (active, hidden, disabled, out_of_stock, draft)
  * (and so on)

This is, roughly, what I shoot for:

  * refund_statuses: (new, pending, partial, canceled, completed, /*possibly some others */)
  * payment_statuses: (new, pending, partial, failed, voided, completed, /*possibly some others */)
  * products: (new, active, hidden, disabled, out_of_stock, /*possibly some others */)
  * (and so on)

I want the "_statuses" tables to have a certain pattern or overlaps in naming so that it'll be less confusing, there'll be less of unique statuses, it'll easier to reason about and refactor them.

However, naming them this way will make it a little less clear.

Evidently, most or all of the "*_statuses" tables will have some unique statuses that exist only in a single table.

How would you propose to go about the matter?

  • The statuses are used in different contexts, so the benefit of having identical names is unclear to me. A "new" refund is not the same as a "new" product, anyways. Why is it better to have fewer unique status names? – Jacob Raihle Jul 3 at 11:36
  • 1
    What is "new" anyway? Put a date on it. New becomes old when no one is looking. Same reason we don't store age in databases. We store your birthdate. – candied_orange Aug 2 at 11:14
0

Do not adopt a set of standard names because you, as the developer, want to. Use the words and the meanings that the users of this application use. If they happen to use the same words for different statuses then that's great. If you can convince them to adopt a common set of words as a change to their day-to-day business practices then that's great too. Defining a your own set of words and forcing them into the application will cause problems for the users and further development work in the future.

Consistency between entities is good. Correctness is better. A data model models something, usually a function within a business. Use the terms used by the business, with the definitions they have in common practice, even if a word in the context of a product has a different meaning in the context of a payment.

The automation of this business function may be an opportunity for aligning terms and definitions across groups of users. Great if it is. But do it in that order - get the business to align the terms, then implement the new terms in the application.

Having the application use different terminology than the people it serves will only cause confusion. It will take longer for them to learn the system, reducing acceptance. Reporting etc will not be immediately familiar, or further mapping from application terms to human terms will be needed, adding complexity to code and maintenance.

| improve this answer | |
  • give me a concreate example – tigrushkada Jul 2 at 12:54
  • I don't know your domain, what user communities you have to support, what vocabulary they employ, or the meanings they apply. Perhaps an analogy from programing will suffice. Think of the definition of "done" in the context of a sprint. No two teams have exactly the same definition. Conversely some teams say "finished", or "complete" but mean the same thing. – Michael Green Jul 2 at 13:04
  • 1
    "get the business to align the terms, then implement the new terms in the application." - this is an important point. Reengineering the vocabulary of a business may be important if it introduces a more logically robust system of language, or if it makes the vocabulary comply better with established professional standards, but any changes should be done in consultation and the overall size of the vocabulary should definitely not be reduced but in compelling cases, because otherwise specific well-known terms will inevitably be replaced with vague jargon that means everything and nothing. – Steve Jul 2 at 13:25
  • Your answer is vague. It doesn't answer my question. – tigrushkada Jul 3 at 8:57
  • @tigrushkada, what exactly was your question? Three people (at time of writing) have attacked the very premise of your question, and have basically advised you not to reengineer the vocabulary as you propose to do. You say yourself doing so will make it "less clear". Therefore, just don't do it - that's your answer so far. – Steve Jul 3 at 18:19

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.