• Todd (unregistered) in reply to Robert S. Robbins
    Robert S. Robbins:
    I would just add a column to the Screen table to indicate the type of ID.

    There probably already was one, the guy probably didn't see it. 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.

    I don't think it's a good thing to have one table and a type field on a table from a data stand point because you can't enforce the relationship but from an application stand point it can be really nice.

  • (cs) in reply to Brave-but-foolhardy
    Brave-but-foolhardy:
    MET:
    oh how i love indexes...
    Am I the only person who gets annoyed by people not knowing the plural of index is indices?

    Actually, according to Fowler, both indices and indexes are valid English, with indices being used mostly in formal and scientific situations, and indexes being used in popular or colloquial situations. But "there is considerable liberty of choice".

    Eg, "the volume is rounded off by splendid indexes" and "Integral, fractional and negative indices" (Fowler's examples)

    So there ;-P

    And, as another who is particular about grammar, this does not annoy me as much as: Orientate Irregardless 'I could care less' ...and a few more.
  • (cs)

    Matt Langley speaks with great insight. But we all must remember this is a [US] State (or Local) Government organization. Audits, Q/A, any 'technical sensibility' do not exist!

  • (cs) in reply to Hudson
    Hudson:
    "What if there are more things they want to record about a case later on? We'll keep adding tables and adding tables and before long there will be double the tables!"

    True. I mean, a database isn't exactly efficient for storing this kind of stuff (data). Better go with something more universal, like Word. Any updates you'd need to do can be conveniently and quickly done with a find/replace all. Lightning fast, end users could even do it, and they wouldn't need to know anything about SQL.

    The best part is, if they want to start formatting the text as it's stored in the "Database", it's all right there man!

    The really hillarious part about this post, is that there are actually people who think that Word is excellent for handling mass amounts of data, that should be kept in a database, or Excel (which is better than word at least).

    One of the most frustrating things about being a DBA is dealing with all the "Excel Databases" that are kept.

  • (cs) in reply to KingNetSurfer
    KingNetSurfer:
    Hudson:
    "What if there are more things they want to record about a case later on? We'll keep adding tables and adding tables and before long there will be double the tables!"

    True. I mean, a database isn't exactly efficient for storing this kind of stuff (data). Better go with something more universal, like Word. Any updates you'd need to do can be conveniently and quickly done with a find/replace all. Lightning fast, end users could even do it, and they wouldn't need to know anything about SQL.

    The best part is, if they want to start formatting the text as it's stored in the "Database", it's all right there man!

    The really hillarious part about this post, is that there are actually people who think that Word is excellent for handling mass amounts of data, that should be kept in a database, or Excel (which is better than word at least).

    One of the most frustrating things about being a DBA is dealing with all the "Excel Databases" that are kept.

    Actually, I hate Access DB's more than Excel ... Usually come with more WTF's ...

  • Synonymous Awkward (unregistered) in reply to MET
    MET:
    Am I the only person who gets annoyed by people not knowing the plural of index is indices?
    My indexes got infected with some virii. :<
  • (cs) in reply to sweavo
    sweavo:
    When dealing with insecuretins , best to get them teaching you. Then if you are skillful, you will be able to get THEM to have your idea.
    Very good! Well said. The desired result is to get the crapola replaced with sleekola, not to prove yourself right.
  • Brave-but-foolhardy (unregistered) in reply to KingNetSurfer
    KingNetSurfer:
    The really hillarious part about this post, is that there are actually people who think that Word is excellent for handling mass amounts of data, that should be kept in a database, or Excel (which is better than word at least).

    I think people were being ironic...

  • (cs) in reply to Todd

    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?

  • (cs) in reply to ParkinT
    ParkinT:
    And, as another who is particular about grammar, this does not annoy me as much as: Orientate Irregardless 'I could care less' ...and a few more.
    Don't forget: I pacifically told him... (at least you were peaceful about it) That's a tough road to hoe (I can imagine it would be) Here, here! (Where, where?) Note: for readers wondering why this is wrong: "Hear, hear" is a way of expressing agreement with a statement made by someone at a public gathering. It means, "The speaker just made an important point! Listen and pay attention to it!" Listen -- as in, "hear". ...and, for dwellers in the southern USA: Don't get above your raisins (how about my banana? Can I get above that?)
  • Bob (unregistered) in reply to snoofle

    Riiighhht......... the new guy, placed on a safe task like reporting while he cut his teeth, should just start making design changes without approval. That's not a recipe for disaster...

    snoofle:
    Soooo not the right way to do this, but given Roy's mandate...

    Screen format for ContextFieldId: 'TableName|Data' [1] 'Case|Big-Int-Value-here' [2] 'Hearing|nvarchar[16]-here' [3] 'Motion|int-here' [4] 'Pleading|nvarchar[32]-here'

    or, if you have the luxory of a limited number of tables, use C, H, M and P respectively as the prefixes.

    Again, sooo the wrong way to do it but sometimes you gotta play by someone else's rules.

    And Joshua's only mistake: going back to the original developer with a suggestion on how to enhance his design instead of just doing it.

  • css ninja (unregistered) 
    CREATE DATABASE wtf;
USE wtf;
CREATE TABLE all_you_really_need
(
    id           INT             NOT NULL,
    fieldname    VARCHAR(255)    NOT NULL,
    value        TEXT            NOT NULL,
    nextid       INT             NULL,

    CONSTRAINT PRIMARY KEY(id),
    CONSTRAINT FOREIGN KEY(nextid) REFERENCES all_you_really_need(id) ON DELETE SET NULL ON UPDATE CASCADE
);

    And yes, I'm kidding. :P

    CAPTCHA: kungfu

  • (cs) in reply to Synonymous Awkward
    Synonymous Awkward:
    MET:
    Am I the only person who gets annoyed by people not knowing the plural of index is indices?
    My indexes got infected with some virii. :<
    I was under the impression that the plural of 'virus' was 'virus' with a long 'u' (it being a neuter noun and all). Of course, if we're going to be silly and latinate about it, we'd have to use 'viris' or possibly 'viribus' in the context above, which properly requires the ablative plural ... Funny how we pedants don't seem to take case into account when tracing back etymology. (Well, we can't, it being almost entirely absent from the English language.)

    The (unusually authoritative) Wikipedia on this topic -- http://en.wikipedia.org/wiki/Plural_of_virus -- is well worth a read. I would have thought that "virii" is just silly, but apparently it's OK (if a tad precious) in the case of computer viruses...

    I think I'll stick with viruses and indexes, thanks.

  • Matthew (unregistered) in reply to ajk
    ajk:
    the problem with such an approach is that it is easy that errors sneak in so the 'type' no longer matches the content of the other columns. the best way is to enforce data integrity at the database level so that programs have no change of entering garbage.

    What, are you programming in assembly or somrthing? If you have a proper framework such as Rails/ActiveRecord that manages model associations for you it really isn't something you need to worry about. Having all your activity logs (or whatever you're working with) in a single table is too valuable to pass up. I use polymorphic associations all the time and they are great. Never once had a problem with "garbage" getting into the "type" column.

  • Matthew (unregistered) in reply to 28% genius
    28% genius:
    alter table hearing add enteredby varchar2(30) default user;

    Insufficient. You want to have a record of all changes, not just adds.

  • barfman (unregistered) in reply to wfwaf
    wfwaf:
    Guy's got a point. Wouldn't want to hit any hard-coded table limits in the database.

    That's a joke, right? damn, is my sarcasm radar malfunctioning...

  • Sgt. Preston (unregistered) in reply to MET
    MET:
    pavel:
    Re: Snoofle

    We actually use something sort of like this in some cases, except we have to columns - itemtype and itemid. Itemtype stores the table name, essentially, or if it's more complex than that, the object type.

    Not ideal, but for instance, we wouldn't want an "images" table for every table, either.

    It would double the number of tables!!

    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?
    I'm no authority on this issue, but I have always thought that the plural of "index" when it meant a way to look up information, as in a back-of-the-book index, was "indexes" and that the plural of "index" when it meant a gauge or indicator, as in "Average life expectancy and rate of infant mortality are common indices of prosperity" was "indices". Maybe it's just my unanalysed take on it.

    We had a senior developer a while back who used "indice" as the singular. That one always cracked me up.

  • Bob (unregistered)
    "If we make all these tables to link everything together, what if they add to the scope? What if there are more things they want to record about a case later on? We'll keep adding tables and adding tables and before long there will be double the tables!" Roy stormed out of the office.

    Amen: Heaven forbid the database should have to change to cope with a change in data model! If you have to make decisions during data design, you're doing it wrong. An Inner Platform is the best kind of platform!

  • Just me (unregistered) in reply to Unfriendly
    Unfriendly:
    Just me:
    It's a sad fact, but this doesn't surprise me. The vast majority of developers I have had to work with do not understand even simple relational database concepts.

    I have had to deal with many systems that have a database comprised of one large table. But that must be the correct way to do thing. Why else would Excel be the #1 tool for creating and storing databases :o

    I even had a "senior" developer once lecture me on how evil table joins were as they were major performance hits on the system. Well he was correct... when joining two tables with ~50K rows each, with no formal relations defined between the tables, and using non-indexed fields to join the tables. sigh.

    Working on an application where some of the tables hold around 1-1,5 billion records (which seems about right for juvenile delinquents...) having everything in the same table is not a good thing....

    with a good datamodel you can support almost any type of application. and indexes... oh how i love indexes...

    Just to ensure there is not any misunderstanding, and in case the sarcasm wasn't dripping enough, my point was that a single table design is (typically) a bad thing. And it was I that had to point out to the "senior" developer that tables joins are not inherently evil. Rather that bad database design and poorly written queries are. (In other words, it was he that was doing the aforementioned non-indexed join, and many similar joins, that caused him to declare table joins the root of all CPU spikes and untimely server deaths.)

  • wondering (unregistered)

    If the backend is MS-Jet (aka Access) then doubling the tables is indeed a bad thing.

  • Some Guru (unregistered) in reply to Ralphie
    Ralphie:
    Premature optimization is the root of all evil.

    "Belated pessimization is the leaf of no good."

  • (cs) in reply to Robert S. Robbins

    Are developers the most intolerant, lazy people on earth or something? Doesn't anyone stand up and fight to make things right? It seems like everyone just suggests "run away from that company".

    This would be like working for a renovation company, seeing a house being built where the foundation structure was compromised, and then just "running away" because you knew it was bad practice, rather than doing something about it. Then the house falls down and crushes a family.

    Seniority be damned, if you know you're right, don't let yourself be stifled. At the very least submit something formal explaining to someone other than the other developers WHY this is going to be a problem in future.

  • LordJeb (unregistered) in reply to FredSaw
    FredSaw:
    ParkinT:
    And, as another who is particular about grammar, this does not annoy me as much as: Orientate Irregardless 'I could care less' ...and a few more.
    Don't forget: I pacifically told him... (at least you were peaceful about it) That's a tough road to hoe (I can imagine it would be) Here, here! (Where, where?) Note: for readers wondering why this is wrong: "Hear, hear" is a way of expressing agreement with a statement made by someone at a public gathering. It means, "The speaker just made an important point! Listen and pay attention to it!" Listen -- as in, "hear". ...and, for dwellers in the southern USA: Don't get above your raisins (how about my banana? Can I get above that?)

    My personal favorite: That's a mute point.

  • Nutmeg Programmer (unregistered) in reply to Robert S. Robbins

    Yeah, but if you keep doing that, you could end up with doulbe the number of columns!

  • CynicalTyler (unregistered) in reply to Nozz
    Nozz:
    Or maybe CHuMP, to represent what you look like after such a silly joke. ;)
    Touché.
  • iToad (unregistered)

    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 devevelopers seem to be fairly common. They learn enough to produce some sort of solution, but never learn enough to do things right.

  • An Old Hand (unregistered) in reply to Soviut
    Soviut:
    Are developers the most intolerant, lazy people on earth or something? Doesn't anyone stand up and fight to make things right? It seems like everyone just suggests "run away from that company".

    This would be like working for a renovation company, seeing a house being built where the foundation structure was compromised, and then just "running away" because you knew it was bad practice, rather than doing something about it. Then the house falls down and crushes a family.

    Seniority be damned, if you know you're right, don't let yourself be stifled. At the very least submit something formal explaining to someone other than the other developers WHY this is going to be a problem in future.

    Developers must not attempt to take responsibility for more than which they have authority. Having given people the information they need to make decisions, each person must be responsible for their own decisions.

    Anybody who tries to tell you differently is trying to sell you something, or make you a scapegoat; consider running.

  • (cs) in reply to Soviut
    Soviut:
    Seniority be damned, if you know you're right, don't let yourself be stifled. At the very least submit something formal explaining to someone other than the other developers WHY this is going to be a problem in future.
    Bless you for your naive altruism. Just as there are levels of tech support starting with the guy in Sriganganagar who asks you reboot (and you ask him to repeat), and you cannot get past him until you have run his course, so there are levels of management, and they too are there for a reason. Upper management does not deal with such minutiae as database schema. They have team leaders and department managers to handle those things. The surest way to get yourself an early termination (other than altering the database schema on the sly) is to go over a head or several in the management hierarchy with your n00b opinion of what's best for the company.
  • (cs) in reply to FredSaw

    I realize there's due process. What I'm saying is I don't like the "if there's a problem, run away" mentality that so many people on these boards seem to have.

    Sure, there's a hierarchy in some (most?) companies that has to be dealt with. But while upper management may not care about database schemas, I'm sure they'll care when the database grinds to a halt and they have to pay loads of money to get it refactored and fixed.

    I'd rather get fired for telling the proud proud captain that his boat has a hole in it, than sink on his ship.

  • (cs)

    I think I've seen that before: in previouse Versions of Microsoft CRM

  • jhunter (unregistered) in reply to pavel
    pavel:
    Re: Snoofle

    We actually use something sort of like this in some cases, except we have to columns - itemtype and itemid. Itemtype stores the table name, essentially, or if it's more complex than that, the object type.

    Not ideal, but for instance, we wouldn't want an "images" table for every table, either.

    It would double the number of tables!!

    So... why don't you have one images table with a FK in the tables whose rows need an image?

  • Todd (unregistered) in reply to T604
    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. :)

  • Ralf Großerhode (unregistered) in reply to Ralphie

    I couldn't agree more.

  • Ralf Großerhode (unregistered) in reply to Ralf Großerhode
    Ralf Großerhode:
    I couldn't agree more.
    OK, next time I click 'reply'. It was an answer to Ralphie
  • nab (unregistered) in reply to Nelle
    Nelle:
    Actually, I hate Access DB's more than Excel ... Usually come with more WTF's ...

    After ~3yrs at a major hedge fund, I beg to differ. If you've never seen an Excel spreadsheet take 2gb of RAM and take 30+ minutes to open it's almost a religious experience.

  • (cs) in reply to ParkinT
    ParkinT:
    And, as another who is particular about grammar, this does not annoy me as much as: Orientate ...

    Bah. "Orientate" is a word.

    It took me a while to get used to the American "oriented", as in "Object-Oriented" which in Britain should be "Object-Orientated". Strangely, my first computer, a BBC Micro of all things, used "program" instead of "programme" (and accepted "disc" or "disk"). Auntie let me down there!

    The shift from the BBC's "COLOUR" to every other language's "color" was also a real pain.

    Of course, in most countries, you program in a foreign language altogether. Anyone remember Apple providing localised scripting with AppleScript?

  • scott (unregistered) in reply to MET
    Am I the only person who gets annoyed by people not knowing the plural of index is indices?

    Yes, because both are correct. Am I the only person who gets annoyed by fools who go around correcting other people without ever even having bothered to check the disputed word in a dictionary?

  • Joon (unregistered) in reply to I-D
    I-D:
    Insecuretins are the number one plague on IT business. Just beyond them are: the big fat liars, the gentlemen, and i-ching/tai-chi-chuang/yoga CEOs.

    You, sir, have just provided my email sig line. Congrats!

  • Wilppu (unregistered)

    Wouldn't adding a few columns to each table (case, hearing, etc.) have solved the problem? Like:

    USER_CREATED USER_MODIFIED

    and maybe even:

    TIME_CREATED TIME_MODIFIED

    Most of the time it should be enough to know when and by who the record was created/last modified, yes?

  • Cheatah (unregistered) in reply to I-D
    I-D:
    "I can see why you chose this design". He's truly a gentleman.

    Or a big fat liar.

    "I can see why you chose this design... you seem to be ignorant and are incompetent because you're lacking the experience you needed to implement this type of system."

    I hate people not finishing their

  • What does it matter (unregistered) in reply to MET

    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

  • What does it matter (unregistered) in reply to KingNetSurfer
    KingNetSurfer:
    Hudson:
    "What if there are more things they want to record about a case later on? We'll keep adding tables and adding tables and before long there will be double the tables!"

    True. I mean, a database isn't exactly efficient for storing this kind of stuff (data). Better go with something more universal, like Word. Any updates you'd need to do can be conveniently and quickly done with a find/replace all. Lightning fast, end users could even do it, and they wouldn't need to know anything about SQL.

    The best part is, if they want to start formatting the text as it's stored in the "Database", it's all right there man!

    The really hillarious part about this post, is that there are actually people who think that Word is excellent for handling mass amounts of data, that should be kept in a database, or Excel (which is better than word at least).

    One of the most frustrating things about being a DBA is dealing with all the "Excel Databases" that are kept.

    The really really hilarious part is that some ('KingNetSurfer') don't seem to understand the concept behind 'sarcasm'.

  • What does it matter (unregistered) 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 devevelopers seem to be fairly common. They learn enough to produce some sort of solution, but never learn enough to do things right.

    Hmm..I would've thought that Type I would be symptomatic of that!?

    The first time they produce some sort of solution that works, they don't have sufficient reason to revisit that design. But if you move on and expose yourself to different environments, you just might get that reason.

  • Cloak (unregistered) in reply to Franz Kafka
    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.
  • What does it matter (unregistered) in reply to Soviut
    Soviut:
    I realize there's due process. What I'm saying is I don't like the "if there's a problem, run away" mentality that so many people on these boards seem to have.

    Sure, there's a hierarchy in some (most?) companies that has to be dealt with. But while upper management may not care about database schemas, I'm sure they'll care when the database grinds to a halt and they have to pay loads of money to get it refactored and fixed.

    I'd rather get fired for telling the proud proud captain that his boat has a hole in it, than sink on his ship.

    If the captain doesn't seem to understand and you don't end up getting fired, then your options are to "run away", or sink.

  • Cloak (unregistered) in reply to Soviut
    Soviut:
    Seniority be damned, if you know you're right, don't let yourself be stifled. At the very least submit something formal explaining to someone other than the other developers WHY this is going to be a problem in future.

    Yeaaaahh! The thing is that they simply don't listen to you because you're an old tarte.

  • Cloak (unregistered) 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 devevelopers seem to be fairly common. They learn enough to produce some sort of solution, but never learn enough to do things right.

    Yes, we see these exprts much too often

  • Cloak (unregistered) in reply to FredSaw
    FredSaw:
    Soviut:
    Seniority be damned, if you know you're right, don't let yourself be stifled. At the very least submit something formal explaining to someone other than the other developers WHY this is going to be a problem in future.
    Bless you for your naive altruism. Just as there are levels of tech support starting with the guy in Sriganganagar who asks you reboot (and you ask him to repeat), and you cannot get past him until you have run his course, so there are levels of management, and they too are there for a reason. Upper management does not deal with such minutiae as database schema. They have team leaders and department managers to handle those things. The surest way to get yourself an early termination (other than altering the database schema on the sly) is to go over a head or several in the management hierarchy with your n00b opinion of what's best for the company.

    Maybe you can do hat in India. Try to do the same for the European Commission and you know how much you are worth.

  • Cloak (unregistered) in reply to Todd
    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?

  • Cloak (unregistered) in reply to What does it matter
    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)

Leave a comment on “The Omni ID”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article