6,795 reputation
1923
bio website mooseware.ca
location Mississauga, Canada
age 52
visits member for 3 years, 4 months
seen 5 hours ago

I'm a professional software developer with more than twenty years of experience across many industries and the entire systems development lifecycle. I'm the principal consultant at Mooseware Limited.

@joelabrown

google

facebook

linkedin


Oct
9
answered ERD Design for Employee Leave
Sep
30
awarded  Explainer
Sep
30
comment Supertyping Inventory Transactions
Agreed. Further to this, if you think you really want to run queries against one particular transaction type, create views on the transaction table(s). If the big table with nulls approach is used, the views on the table will almost certainly be writable as well.
Sep
28
comment Database design : hotel room and its detail
Room type and room size on a room description table might violate 3NF if the type and size depend on the room, not on the description of the room. You don't state your assumptions about dependencies, you just split a bunch of properties of rooms off from the rooms table in a way that might be creating transitive dependencies. Your inference of my logic is in exactly the opposite direction.
Sep
28
reviewed Close get mysql index size split by index
Sep
28
reviewed Leave Open MySQL lost connection
Sep
28
awarded  Custodian
Sep
28
reviewed Leave Open Disaster Recovery Options for Sql Server
Sep
28
reviewed Close CROSS JOIN and updatable model design for Ruby on Rails
Sep
28
comment Database design : hotel room and its detail
A table of code tables (your Type 2) is generally considered to be an anti-pattern. You should probably avoid it. If you are concerned about the number of tables in your database you might use something like schemas to allow you to focus on an area of interest while "ignoring" the other areas in your database. Alternatively, you could (and probably should) just come to terms with your aversion to many tables. Any real world business system will have lots of tables.
Sep
28
comment Database design : hotel room and its detail
It looks to me like you are suggesting blending room type and room size? Or are you creating a three tier structure: room -> room_description -> room_type (and other lookup tables, such as room_size)? If the former, that would not be third normal form. If the latter, why introduce a middle tier? What non-key attribute do you expect to depend on a description code?
Sep
15
answered How to represent foreign key in an ER diagram?
Sep
7
reviewed Approve Best practice database design - user rating tables
Sep
7
answered Best practice database design - user rating tables
Sep
6
comment Need Help in DFD Diagram for online hotel booking system
Data Flow Diagrams are well suited to documenting systems where data is stored in files or systems where there is some ETL involved. In a transactional system built on a relational database, your data doesn't "flow" anywhere. The only information in your DFD is actors and actions. What you want is probably more something like a Use Case Diagram, not a Data Flow Diagram.
Aug
30
comment How to store user's language knowledge (150+ languages) in mysql DB
Correlated sub-query is the way to go as far as clarity of code is concerned, but are your sub-queries correlated? Shouldn't it be more like: from dbo.user A and WHERE user_id = A.user_id ?
Aug
29
reviewed Approve DB2 Materialised Query Table performance problems
Aug
28
awarded  Yearling
Aug
23
comment Is one-to-one relationship normalized?
@Gili - re: the cost of joins: There is no right answer to that question aside from "it depends". Join cost is impacted by many factors. Whether they are negligible is even harder to answer, because that is ultimately subjective. The best way to answer you question is to mock up some test data and do volume testing. Try it both ways and see if you can tell the difference using real world data volumes (whatever that implies for your application).
Aug
22
comment Is one-to-one relationship normalized?
@Gili - If your assumption were true then this case wouldn't apply. Segregating large and infrequently needed columns allows more rows to fit on a page, thereby allowing faster retrieval of the commonly used columns. Obviously reading the segregated columns along with the commonly used columns would be slower since a join is necessary.