• What does it matter (unregistered) in reply to Cloak
    Cloak:
    What does it matter:
    It's quite possible you are the only one.

    Since you haven't a clue, here's a starting point... http://www.answers.com/indexes&r=67

    Cheers

    Well, a stock exchange index is not a database index. The first one is indicating a tendency whereas the latter one is showing you where some data is located. Not really the same thing.

    CAPTCHA: sanitarium (where we will all end up)

    If you're trying to suggest that an index has multiple meanings, then you're correct.

    Now regarding the plural form of the word 'index', it isn't incorrect to use 'indexes' in all cases, which by the way has been the point of this argument.

    That aside, there is no requirement that suggests the plural form 'indices' must be used in relation to a specific meaning of the word 'index'.

  • (cs) in reply to soulfly 69
    soulfly 69:
    only mistake: going back to the original developer with a suggestion on how to enhance his design instead of just doing it.

    Truest thing I've heard in a long time.

    Agreed. This could backfire however. I have been the original developer in a project and the new guy went ahead and made changes without a suggestion. Now we have a bunch of html forms with blue text fields. Cause black text on blue background had the best contrast.

  • Hognoxious (unregistered) in reply to MET
    MET:
    I really, really hope this is missing it's sarcasm tags.
    oh how i love indexes...
    Am I the only person who gets annoyed by people not knowing the plural of index is indices?
    Yes. Now am I the only one who thinks that people who don't know to use apostrophes correctly should be boiled alive in ripened goats' piss?
  • Todd (unregistered) in reply to Cloak
    Cloak:
    Todd:
    T604:
    You do realize there is another way to do this where you can enforce integrity.

    You have your table of (going back to the original post) images. Then each table that needs an image (be it item, location, employee, sex toy whatever) has a fk column that links back to the image table. You can even make the fk nullable. No silly object_type field needed.

    "I did the same thing for addresses, had and ObjectID and and ObjectTypeID column, then some other developer couldn't figure out how to get a customer's or vendor's address."

    Um... he should just get it from the customer or vendor table and follow the fk back to the address.

    Does it get any simpler?

    There were multiple addresses and the number and types of addresses for an object type could be changed by a user. If done your way and they needed another type of address you would have to do more work.

    I forgot to mention an AddressType table, and that is what actually held the ObjectTypeID.

    My way, I just tell a user to change it themselves. :)

    Ooops, where is the problem?

    if an item, location, employee, sex toy need to have multiple images you are going need a multiple columns in each table (item, location...) Say, if they want another type of image for say an item then you have to add another column again to the item table. Read the story again, he wanted to add linking or mapping tables for each table, which is a good solution to handle the multiples. Someone else mentioned adding a type id to the screen table, to me that is the one that requires the least amount of work although still not the best way. For my addresses example, the user wanted to be able to add new types of address.

  • Mkdir (unregistered) in reply to Cloak

    The problem with that is you only get the LAST person to change a record and not an audit trail.

    Suppose this is a HR system...

    So let's say that John changes Susan's payroll record to give her a $5000/year raise and he now is stamped as the person that changed the record. Susan now asks Carol in HR to update her address and Carol doesn't notice how much Susan is now making (it could be on a different screen that edits part of the same record). Now, when somebody eventually finds this change, they think that it must have been Carol.

    A singular column of who was the last person to modify a record never gives meaningful information.

  • Mkdir (unregistered) in reply to Mkdir

    Dang it, that was in response to:

    Cloak:
    Franz Kafka:
    Why we can't just add columns everywhere for last_updated_by and add triggers i dunno - we do it here and it mostly works, except when it's oracle that does it.
    Oracle does it also. I always include columns CREATED datetime, CREATED_BY varchar(50), CREATED_WITH varchar(50), CHANGED datetime, CHANGED_BY varchar(50), CHANGED_WITH varchar(50). The "*_WITH" column can often be omitted but sometimes it can give raise to insights that otherwise would not have been possible (malicious user logging in to another machine). Simply don't use the database user but the Windows logon to trace user activity.
  • (cs) in reply to Hognoxious
    Hognoxious:
    Now am I the only one who thinks that people who don't know to use apostrophes correctly should be boiled alive in ripened goats' piss?
    Regarding goats' piss (better rendered as simply "goat piss") -- its a well known fact that it's green version is not as potent as it's ripened version.

    Couldn't resist. However -- tell us how you go about collecting enough of said goats' piss for the boiling.

  • (cs) in reply to iToad
    iToad:
    It seems like there are two types of senior developer:

    Type I - Ten years of experience. Type II - One year of experience, ten times.

    Type II senior developers seem to be fairly common. They learn enough to produce some sort of solution, but never learn enough to do things right.

    A friend of mine came up with this description of a 55 year old colleague:

    "He went straight from Junior Programmer to Senile Programmer without stopping in between."

    Things got so bad that we instituted a rather novel procedure called the "Ron Alert." The youngest member of the team was allowed to come in wearing sneakers (c'mon, it was a banking environment) and, whenever anyone make a "whoop whoop" siren noise, his job was to run over to Ron's desk and to tell him firmly, on pain of being beaten up, to stop what he was doing immediately.

    It brightened up our days and improved productivity no end.

  • sarcastic steve (unregistered) in reply to real_aardvark

    Wow, sounds like your development team is really cool.

    real_aardvark:
    iToad:
    It seems like there are two types of senior developer:

    Type I - Ten years of experience. Type II - One year of experience, ten times.

    Type II senior developers seem to be fairly common. They learn enough to produce some sort of solution, but never learn enough to do things right.

    A friend of mine came up with this description of a 55 year old colleague:

    "He went straight from Junior Programmer to Senile Programmer without stopping in between."

    Things got so bad that we instituted a rather novel procedure called the "Ron Alert." The youngest member of the team was allowed to come in wearing sneakers (c'mon, it was a banking environment) and, whenever anyone make a "whoop whoop" siren noise, his job was to run over to Ron's desk and to tell him firmly, on pain of being beaten up, to stop what he was doing immediately.

    It brightened up our days and improved productivity no end.

  • aron (unregistered) in reply to snoofle

    I like that solution, nice work. I would just recommend a few changes...

    [1] 'Case|Big-Int-Value-here' [2] 'Hearing|nvarchar[16]-here' [3] 'Unknown|nvarchar[256]-here' [4] 'Motion|int-here' [5] 'Pleading|nvarchar[32]-here'

    That way, you can call it the "chump" table.

Leave a comment on “The Omni ID”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article