Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 months ago.
Improve this question
I have to store in database
[Column 1], [Column 2-start datetime]
Version1_1, 01-01-2011
Version1_2, 01-01-2011
Version1_3, 01-01-2011
…
I have a class with two fields: the version name and the datetime (+id).
The version name represents the first column. It can be an enum or a static class with constants.
Regarding almost any scenario I understand enums are better. But then, The DB will store integers in the first column instead of string values. Which gives me a feeling of uncertainty.
Are the enums still the best option in this scenario? I don't see disadvantages in lacking clean string values in [Column 1] in database.
If you store the values as integers in the database, you have several advantages:
Less storage space required
Easier querying without taking string comparisons into account
Better query performance because integer comparisons are much faster than string comparisons
A disadvantage on the database side is of course the reduced readability, but considering the advantages, I'd prefer integers in the database.
On the C# side, enums let you have the best of both worlds: integers inside and at the same time text identifiers when working with the values.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
C# Why do arrays and collections have a difference between the names of the same attribute (Count and Length)?
It just causes headaches to people that are not familiar with this matter.
Length generally refers to a fixed size, whereas Count generally refers to content which could change. (I say generally because there are some exceptions to this, such as an IReadOnlyList which isn't going to change, but still has a Count since it is based upon a more generalized List interface.)
Besides #McGuireV10's answer part of the reason is historical. C# has it's roots in C, which use the "length" term when talking about arrays and strings. There was no compelling reason to not use "length".
Over the years, collections have been refined, genericized, and hold all kinds of different, countable objects, so "count" also makes sense.
I think another part of this is how we talk about our data structures. It is more natural to say, "what is the length of the array" than "what of the count of the array"; the former sounds natural, and the latter is ambiguous (did you mean count of items in the array or *the number of arrays".
Similarly when answering, "how many widgets are in the dictionary"? you are going to express your answer in terms of a count, not a length.
For something like a string, it's not wrong to think of it in terms of both count and length:
This string has (a count of) 40 characters
This string has a length of 40
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I do have a database with multiple tables that represent different parts of the same DD object:
DD(ID*, name) (the name and ID of the DD)
DD_DATA(ID*, DD_ID(foreign_key), MONTH, YEAR, VALUE) (its annual data)
DD_MODEL(ID*, DD_ID(foreign_key), X_value, Y_value, Z_value) (its mathematical model, using a fk since it's a one-to-many relationship)
Since it's a huge application, I went to using ORMs, but I'm new at this. Currently I'm benchmarking and trying a lot of them, so I didn't settle yet with which one to use.
My question: Can (at least one) ORM be set to map these tables into a single object and translate the DD_DATA and DD_MODEL tables into some kind of arrays (or objects) inside one single DD class? Or do I have to do this by hand (I mean, creating a DD object and then extracting all its data by hand).
In Dapper, the mapping is done based on the results of whatever query you run. Your query can join many database tables - as long as the resulting column names match up to the object properties that you are mapping, you will be fine.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Let's suppose we have 2 tables:
Person
ID
Name
Nationality_ID (FK)
Nationality
ID
Name
With EF, in what contexts does it make sense and is correct to use each of the options below to add a nationality to a person? What is the different between them? What is the faster and the slower?
Option 1:
TheNationality.persons.Add(ThePerson);
Option 2:
ThePerson.nationality_id = TheNationality.id;
Option 3:
ThePerson.nationality = TheNationality;
If Person is the root of your aggregate and the focus of your application, most likely option 2 and option 3 make sense. Of those, option 3 is the more useful if you need to do additional domain logic based upon information in your nationality. Option 1 makes sense if the focus of your application is about nationality.
None of these methods is mutually exclusive. If you query and manipulate the objects from both perspectives, you can use options 1/3 or 1/2.
The resulting insert/update would be the same in all cases. Unless it is necessary to get TheNationality entity for some other reason, you could skip the read to obtain that and just assign the ID if you have it:
ThePerson.nationality_id = someNationalityIDVariable;
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm refactoring some legacy code that uses a 2D string array:
/// <summary>Array of valid server messages</summary>
private static string[,] serverRsp =
{
{"JOIN", "RSP" },
{"SETTING", "RSP" },
. . .
I want to modernize this, but don't know if I should use a Dictionary, a List of list of string, or something else. Is there a standard correlation between the "olden" way and the golden way (legacy vs. refactored)?
IWBN (it would be nice) if there was a chart somewhere that showed the olden vs. the golden for data types and structures, etc.
[,] is not an "old" datastructure, and hopefully will never become.
Keep using it whenever appropriate.
For example:
just in this case have a List<List<T>> is much more confusing then having simple 2 dimensional array.
It's lighter then List<T>in terms of memory consumption (at least from my measurements).
In short: if there is no any real reason, or new requirement to change it, like make it faster O(1) access data structure key-value store (for non index, hence key like, fast access), do not change it. It is clear and it is readable.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Maybe you consider this question trivial but im just curious what is your opinion.
I have three radiobuttons. "Show blue", "Show red" and "Show all".
I did it with nullable boolean. There is collumn in database where blue is 0 and red is 1 so in metode i have to translate bool to int to compare those values (i do it in c#).Of course it works, but i wonder if it is the best solution.
And question is wich type is best in this case? nullable bool, int, or maybe string?
bool only has two possible values, true or false. If you need to represent more values you need to store it in some other way.
Using null value as the third value is an ugly code hack.
From wiki:
a good way to remember what null means
is to remember that in terms of information, "lack of a value" is not
the same thing as "a value of zero"
That is, null is to be used when you do not have a value.
In your case, using an enum will be easier to read and understand and also you will be able to add more options later if that need arises.
enum MyTypes{
blue = 1,
red = 2,
all = 3
}
In a database an enum becomes an int column containing the value of selected option.