ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

%bitand

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • %bitand

    It has been suggested by a BA who also happens to be fairly "techy" that we use BIT processing to determine if specific conditions are met.

    This is his reasoning; I don't know where he got it. I added the bold format:
    "The concept of Enumeration (also referred to as bit flags) allows many “flag” values to be stored in one field. A flag field is a Boolean data type meaning the value is either 0 (false) or 1 (true). The value of the flags can be updated or read using bitwise operators AND, OR, and NOT. The traditional way of storing these values is to use a separate database field for each flag. However, adding a flag requires changes to the code that evaluates the value of the flag and requires a new field to be added to the database. Using enumeration, adding a new flag requires code changes, but not database changes."

    So, I get the concept, I think, but I wonder if it's worth it. To me, this is making the program more complicated to maintain by "normal" developers later on and "old-school" developers in general. Especially since we're using it to decide whether or not to highlight differences in the data. For example, most of our inventory is counted in "Each" but some are in "MP" (1,000 pieces), and on the screen that we're building, they want us to highlight the MP so it's obvious.

    History tells me that they will have other things that they want to highlight in the future, so if we just use flags in the table, we'll have 5 now and will have to add 15 later. The BA who is asking for this has had bad experiences with the old physical files that we use (and developers have been afraid to change!), but now we use SQL tables for about everything and I've found it very easy to add fields.

    I respect everyone on this forum, so I have to ask: should we do this or should I fight him and tell him not to worry about HOW we do what we do. What do you think?

    As always, thank you for your time.

  • #2
    I wouldn't use bits to store Boolean values. The SQL would be messy with AND's, OR's and NOT's. Suppose you needed to build an index on one of those bits. How would that work? For that matter, what would the optimizer deal with bits? I'd stick with separate fields, especially since the latest DB2 for i enhancements include the Boolean data type.

    Comment


    • #3
      That should be "how would the optimizer deal with bits". I wish I could edit my posts.

      Comment


      • #4
        IMO there are very few situations where you should need bitwise operations in a business application. They're harder to query, update, and understand.

        If I'm looking at a snippet of code and trying to understand what it does, I would much rather see references to a well-named, self-describing column instead of "bit 13 of misc_flags". The bitwise approach requires you to have separate documentation for what each bit does, and track which ones are actively in use.

        This seems like a code smell that would suggest poor change management for database changes. I would suggest you treat the underlying cause, and make it easier to change the database... but it sounds like you are already in a good position there! So why even bother?

        Comment


        • #5
          As I understand it, the "not database changes" warning refers to the fact that you cannot use a bit flag as a search key. You can construct a key from the full value of a field, but not from the value of a single bit in it. If this field is not used as a key to search for individual bit values in it, then no one forbids storing it in the database. Moreover, you can even build a key from it, but you can only search by the full set of bits, and not by the value of a single bit in it.

          Comment


          • #6
            The term "enumeration" just means assigning numbers to something. While it certainly could be used to create constants that are used as bit flags, it's a much broader term than that and can mean other things.

            Second, this is a poor database design. It's nice for an in-memory variable design, because it's very efficient on space and performs well. But in a database, I think it would result in poor maintainability. You wouldn't ever be able to use bit values in an index, for example, so if you have to search them, it'd be inefficient. Whenever you listed the contents of the table, you'd need to use a fair amount of code to make it readable. I wouldn't design a database this way.

            Comment


            • #7
              When changing the file you could add a number of fields for status purposes for future use.
              When you need a new field you change the text in the file and make the nescessary changes in your programs.
              Then you don't need to change the record layout for the file.

              I agree that using bit flags is not good.

              I don't know how effective the RPG function %bitand() is but the BITAND operation was very ineffective.
              Many years ago I optimized a program using BITAND that took 4 hours to run to finish in 20 minutes.
              It was the BITAND operation that was the cause.

              Comment


              • #8
                Thank you so much for all your input. I was pretty much against using it from the start, but had to go through the process of asking so that I had "ammo" when the business analyst started arguing with me

                Once again - the people on this forum are SO wonderful! I hope the weather wherever you are is beautiful and you have a good weekend.

                Comment


                • #9
                  Originally posted by TedHolt View Post
                  I wish I could edit my posts.
                  You can't ?
                  I can, but if I edit too many times, it flags it as spam (grrr)

                  Comment

                  Working...
                  X