Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Personally I prefer the first solution, possibly with an additional property which returns <em>all</em> the values.</p> <p>It's much more OO - enums are basically "named numbers", that's all. Everywhere else in code, state is stored in properties - so why use attributes instead? As Eric Lippert wrote in a <a href="http://blogs.msdn.com/b/ericlippert/archive/2009/02/02/properties-vs-attributes.aspx" rel="nofollow">blog post comparing the two</a>, "Attributes are facts about the mechanisms". You're basically using them as a way of providing data about values instead, and that just feels wrong to me.</p> <p>Your first two objections to using POCOs in terms of the potential mismatch between code and the database doesn't ring true either - because they're exactly the same for enums as well, aren't they? Besides, it's very easy to write a test which validates the data - you could even do so on startup if you wanted.</p> <p>It's not clear what the rest of your <code>AssetClass</code> does, but if it only has a <em>private</em> constructor, then you get a lot of the benefits of enums in terms of a limited, well-known set of values, but without the problem that enums are basically just numbers.</p> <p>In fact, the POCO solution is <em>better</em> than the enum in terms of value limitation - because the only "invalid" POCO value is null, whereas it's easy to come up with an invalid enum value:</p> <pre><code>FooEnum invalid = (FooEnum) 12345; </code></pre> <p>Are you going to check for that everywhere? Generally null references go bang considerably earlier than invalid enum values, and are also easier to check for.</p> <p>One downside I can think of in the POCO approach is that you can't switch on it. There are ways around that, but they're not terribly pleasant - you'd basically have to <em>also</em> have a set of well-known numbers (which could be an enum, of course) so that some property would return that and you could switch on it.</p>
    singulars
    1. This table or related slice is empty.
    1. POOpinion requested: for static values, is it better to use Enums or Entities?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USJon Skeet
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POOpinion requested: for static values, is it better to use Enums or Entities?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COMany thanks for your reply! I think my choice of AssetClass as an example was probably not very wise (because it feels like a proper Entity indeed), but what about something like a 'Status', which only has 'Estimated', 'Confirmed', etc. as values? Why bother storing those static-and-will-never-change values in the database, while what they really represent is a "flag"? Now I can really see your point, and I'm starting to understand my colleagues point of view better... Also: I disagree with your value limitation point, since I'd be storing my enum as strings in the DB
      singulars
      1. PO
      1. USAntoine Jaussoin
    2. CO@Antoine: If they're *just* a single numeric value, then it's more reasonable to use an enum. You'd *still* need to validate that you had the right data though. If you were using the POCO solution already in other places, I *might* use that even for just a single numeric value, for the sake of consistency and the possibility of adding behaviour and more information later on.
      singulars
      1. PO
      1. USJon Skeet
    3. COThey are really single numeric values, the only exception is the "proper english" name you can't have directly from an Enum value (Actually on some past projects I wrote some code that would automagicaly convert a "ThisIsAValue" into "This Is A Value"), which is why I used to use attribute for this. But I now understand better my colleagues point of view, and I will tell them they won the argument :)
      singulars
      1. PO
      1. USAntoine Jaussoin
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload