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?

Improve this question
3
  • 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? Commented Jul 3, 2020 at 11:36
  • 2
    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. Commented Aug 2, 2020 at 11:14
  • I don't understand what problem you are trying to solve here. The fact that these statuses exist in separate reference tables strongly implies they are not related to each other. What is the point of trying to impose common values across disparate tables? I don't think it will make it less confusing. Quite the opposite. Commented Mar 31, 2021 at 19:48

1 Answer 1

Reset to default
1

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
5
  • give me a concreate example Commented Jul 2, 2020 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. Commented Jul 2, 2020 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. Commented Jul 2, 2020 at 13:25
  • Your answer is vague. It doesn't answer my question. Commented Jul 3, 2020 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. Commented Jul 3, 2020 at 18:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.