151 reputation
9
bio website
location Germany
age 30
visits member for 1 year, 11 months
seen Nov 26 at 14:16

Nov
27
awarded  Tumbleweed
Nov
20
comment I want to understand clearly why can't we instantiate an object of an abstract class
It's the other way round. It's not that there were always abstract classes and somebody decided that we'll forbid the programmers to instantiate them, just to spite them. It's that sometimes a library designer needs a class which cannot be instantiated. The language creators gave them abstract classes to fill this need.
Nov
20
asked Where to override the design of jQuery UI elements?
Oct
12
awarded  Popular Question
Oct
23
revised Throwing exception from a property when my object state is invalid
Pointed out that I am not seeking an answer to the general question (which is already answered elsewhere with "it depends") but that it is about the specific case.
Oct
23
comment Throwing exception from a property when my object state is invalid
To those who think that this is a duplicate: Maybe I wasn't able to express my intention clearly enough. The other question asks, is it generally bad to throw the exception. The answer is: generally yes, but in special circumstances, it is allowed. The current question is: Is the situation I describe one of those special situations? As such, it complements the other question, and does not duplicate it. I would be glad for suggestions how to edit the question to make it more clear.
Oct
22
comment Throwing exception from a property when my object state is invalid
I'll count this as a vote in the "it is OK to throw exception from a property in this case" camp, because this is what your solution suggests to do. Note that the solution as proposed does not solve my problem, it works only as long as my code is the only agent which writes to the database, which in real life is not the case. I could put the validation into the get parts, refusing to build an object from wrong data, but it has its own problems (I either have to allow for null in entity refs and entity sets, which makes my objects unsafe again, or mock the whole object graph for tests).
Oct
22
comment Throwing exception from a property when my object state is invalid
Yes, this was presented as a simplification, the actual code is usually a "real" property. And I cannot validate the data before I create it, it is Linq that creates the object automatically for me, using whatever data is present in the database. This is the whole point of the question - there are cases where I cannot validate first.
Oct
15
asked Throwing exception from a property when my object state is invalid
Mar
26
accepted Should lookup tables enumerating strings have an integer primary key?
Mar
25
awarded  Commentator
Mar
25
comment Should lookup tables enumerating strings have an integer primary key?
@gbn Actually, I haven't yet decided which version to use. I asked this question exactly because I wanted to hear all drawbacks before committing myself to an option. I have seen examples of using meaningful strings as IDs in textbooks and lecture notes which do teach normalization too, so I was just surprised to hear that it is considered non-normalized, that's why I tried to get more info from the people who said this.
Mar
25
comment Should lookup tables enumerating strings have an integer primary key?
Thank you for this example. While I had thought of the possiblity that I would have to change the database design (such as multiple classification), all cases I came up with would have worked with reusing strings as well as with reusing integers, or would have required such a radical redesign that all keys would have had to be changed anyway. Translation looks like an example where reusing integers would work well, while reusing string names, while still technically possible, would lead to a very confusing design.
Mar
25
revised Should lookup tables enumerating strings have an integer primary key?
added 1 characters in body
Mar
25
comment Should lookup tables enumerating strings have an integer primary key?
@Telastyn I think the "Choose the rows to use" sentence was just a bad formulation on my part. I fully intend to use foreign key constraints. My point was that the users will not be able to add new rows to the LiteraryTypeTable from anywhere in the interface, or to type in free text for the Type field of the LiteraryWork table, so that I won't end up with a "Fairytale" entry as well as a "Fairy tale" entry.
Mar
25
comment Should lookup tables enumerating strings have an integer primary key?
@MichaelT I read it. To put it in terms of this article, what I am saying is, "the type of a Literary Work is a candidate key in its own right, just like a SSN in the example, so if I use it instead of an artificially added autoincrementing column, normalization is not broken". I also clarified my question to say what I am not trying to do. If there is still a mistake in my thinking, could you please explain it, in terms of the article you linked, exactly what the mistake is? Which normal form am I hurting, and why? I am not yet sure if I really made a mistake, or if you misunderstood my q.
Mar
25
revised Should lookup tables enumerating strings have an integer primary key?
Added example about which normalization rule I am not hurting
Mar
25
revised Should lookup tables enumerating strings have an integer primary key?
added that the question concerns exclusively lookup tables, not entity tables.
Mar
25
comment Should lookup tables enumerating strings have an integer primary key?
I cannot see how a data modification anomaly risk is created. As long as I am keeping the second table and using a relationship to it, I can have the type 'Novel' in my system even if I don't have a single record of a novel, so no insertion or deletion anomaly. Also, there is no other information associated with a LiteraryWorkType beside its name, so there cannot be an update anomaly. Could you please give an example of an anomaly which would occur in the second design?
Mar
25
asked Should lookup tables enumerating strings have an integer primary key?