I'm reflecting classes, building a query and inserting all information contained in those classes into a table.
I'm debating on flagging bits to keep track of isInterface, isAbstract, isInherited, etc. Back in the day I used to set bits for flagging object conditions in C, and was wondering if this was still the best way to go about it? I figure 1 INT in a table would be better than a long delimited string or multiple columns.
Bitwise
Moderator: General Moderators
Re: Bitwise
And I'm not really asking a MySQL schema question, I'm asking because I'd be creating functions to check and set flags, define globals for flags etc. I'm just not sure if this is still the preferred method, I'd also be setting the flags in the object instead of using an array.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Bitwise
It is not clear to me what you are trying to achieve. Can you give more detail and perhaps some examples?
(#10850)
Re: Bitwise
Will these flags be mutually exclusive or can several of them apply to the same record?
I, too, have used bitwise flags in the dim dark past, but they create far more complexity in the initial coding and any maintenance, in today's computing environment. Certainly storage space is no longer a consideration. If choices are mutually exclusive, I'd suggest considering enum data type in the database and just using string values. Multiple columns are seriously bad database design. If choices are not mutually exclusive, what you have is a many-to-many relationship, which must be implemented with 3 tables. That may seem complex if you are not experienced with relational databases, but it is the cleanest way to model many-to-many relationships.
I, too, have used bitwise flags in the dim dark past, but they create far more complexity in the initial coding and any maintenance, in today's computing environment. Certainly storage space is no longer a consideration. If choices are mutually exclusive, I'd suggest considering enum data type in the database and just using string values. Multiple columns are seriously bad database design. If choices are not mutually exclusive, what you have is a many-to-many relationship, which must be implemented with 3 tables. That may seem complex if you are not experienced with relational databases, but it is the cleanest way to model many-to-many relationships.
Re: Bitwise
Thanks for your response Cal.
Back in the day, I was the main coder of a modified complex MUD structure. We used hashes to create linked lists of character, NPC, rooms, etc. I would predefine the bits for each flag (e.g. IS_NPC, IS_HOSTILE, IS_VICTIM) etc, all in the same integer. I used big INTs back then, because we had many... many flags for each object.
I agree, that multiple columns is just bad design practice. I have always tried to conform to the KISS theory (keep it simple stupid).
The flags that would be set, would apply to all entries in the specific column. If isInterface is set, obviously isMethod will not be. I'm just trying to find a way to keep everything in one table, but I may be trying too hard. Coming from a 10 year hiatus from C programming, a lot of my design patterns are probably outdated. (Though I have 3 books coming today or tomorrow regarding advanced PHP5 OOP patterns)
I will look into enum data. I haven't worked with MySQL since about 2000 when I used to admin Unix, and even then it was just enough to keep people happy. Thanks for the response.
*edit* the only reason I considered a bitwise method was because I'll have about 15 flags to set and I didn't want a cluttered table.
Back in the day, I was the main coder of a modified complex MUD structure. We used hashes to create linked lists of character, NPC, rooms, etc. I would predefine the bits for each flag (e.g. IS_NPC, IS_HOSTILE, IS_VICTIM) etc, all in the same integer. I used big INTs back then, because we had many... many flags for each object.
I agree, that multiple columns is just bad design practice. I have always tried to conform to the KISS theory (keep it simple stupid).
The flags that would be set, would apply to all entries in the specific column. If isInterface is set, obviously isMethod will not be. I'm just trying to find a way to keep everything in one table, but I may be trying too hard. Coming from a 10 year hiatus from C programming, a lot of my design patterns are probably outdated. (Though I have 3 books coming today or tomorrow regarding advanced PHP5 OOP patterns)
I will look into enum data. I haven't worked with MySQL since about 2000 when I used to admin Unix, and even then it was just enough to keep people happy. Thanks for the response.
*edit* the only reason I considered a bitwise method was because I'll have about 15 flags to set and I didn't want a cluttered table.
Re: Bitwise
I've even gone to the extent of coding a different boolean value for each bit and using bitwise operations to determine which bits are on or off, but I certainly wouldn't do that today.
I would say that today's environment places more value on creating code that can be easily read and maintained, even by someone other than the original author. Unless you're coding for a tiny embedded device, speed and efficiency and storage space are inconsequential compared with functionality and maintainability. I'm not suggesting that you ignore efficient algorithms and such, but that the challenge is to create code that is easily tested, debugged, and modified. There was a time when I would strive to minimize the lines of code or the size of the data store, but those are not very important anymore.
But your database schema is different. It's not a matter of just keeping it simple, it's the hard fact that relational databases and the SQL language are based on mathematical set theory, which is often non-intuitive, and simply won't let you extract some information if it is structured incorrectly. If your new books don't cover the work of E. F. "Ted" Codd, the IBM mathematician who developed the "relational model" around 1970, you definitely should read about that. Decisions about structuring data in tables can make your life easy as you develop your application, or they can be a source of headaches, even requiring you to redesign the entire application, and using commonsense approaches can sometimes lead you in precisely the wrong direction.
I would say that today's environment places more value on creating code that can be easily read and maintained, even by someone other than the original author. Unless you're coding for a tiny embedded device, speed and efficiency and storage space are inconsequential compared with functionality and maintainability. I'm not suggesting that you ignore efficient algorithms and such, but that the challenge is to create code that is easily tested, debugged, and modified. There was a time when I would strive to minimize the lines of code or the size of the data store, but those are not very important anymore.
But your database schema is different. It's not a matter of just keeping it simple, it's the hard fact that relational databases and the SQL language are based on mathematical set theory, which is often non-intuitive, and simply won't let you extract some information if it is structured incorrectly. If your new books don't cover the work of E. F. "Ted" Codd, the IBM mathematician who developed the "relational model" around 1970, you definitely should read about that. Decisions about structuring data in tables can make your life easy as you develop your application, or they can be a source of headaches, even requiring you to redesign the entire application, and using commonsense approaches can sometimes lead you in precisely the wrong direction.
Re: Bitwise
I'm looking Codd up now, thanks for your suggestions Cal.