Many people believe Hungarian notation is bad. How then do you name a variables that represent the same value casted to different types?
I've got a variable called value, that might be a string, or a decimal. What would you call the different formats? strValue, decValue? valueAsString?
I think it would largely depend on the context. For instance if the string value was named age, and the decimal was the parsed value then perhaps parsedAge or something along those lines. Really it comes down to what makes sense given what you are doing and the lifetime of that variable. If it only exists long enough to actually collect and parse the value, then I would give the better name to the parsed variable or worry less about the naming of the intermediary.
If you actually need to hold on to both values, then I might consider creating a struct or some similar data structure that represents the various forms for that data value to prevents the need to shift between string and decimal formats etc.
Related
I need to create a Z table to store reasons for modifications of a certain custom object.
In the UI, the user will pick a reason ID and then optionally fill a text box. The table will have more or less the fields below:
key objectID
key changeReasonID
changedOn
changedBy
comments
My doubt is with the comments field. I read the documentation about the limitations of STRING and SSTRING, but it's not clear to me if a STRING type field used in a transparent table has a limited length or not.
Even if the length is not limited (at least by the DB), I'm not sure if it's a good idea to use this approach or would you recommend CHAR/SSTRING types with a fix length instead?
**My system is running MSSQL database.
Strings have unlimited length, both in ABAP structures/tables, and in the database.
Most databases will store only a pointer in this column that points to the real CLOB value which is stored in a different memory segment. As a result, they restrict the usage of these columns, and may not allow you to use them as a key or index.
If I remember correctly, ABAP supports a maximum of 16 string fields per structure, which naturally limits its use cases. Also consider that ABAP structures have a maximum size.
For your case, if the comment will remain the only long field, and if you are actually fine with storing unlimited input (--> security constraints?), string sounds like a reasonable option.
If you are unsure what the future will bring, or to be on the safe side regarding security, you might want to opt for sstring or simply a long char instead.
I know its a silly question but I want to know what is a good practice when I save a int value in database instead of char.
When I want to save weeks in database.
I think if we save a char value in database its more descriptive.
So tell me which one is good and why?
There is any performance issues or not?
char does not make it more descriptive. If you are going to use that value for anything in the database it will have to be converted to a number anyhow.
If the max value is going to be 52/53 (depending on week/isoweek) then use tinyint. Otherwise use some other integer data type.
Another potential issue is sorting. If you are going to sort on week, are you going to store leading zeros so they sort in order just to use a char data type, or leave it sorting as 1, 11, 12..?
This sentence ist the problem:
I think if we save a char value in database its more descriptive
The values in a database should not be designed to be descriptive.
One should always store values in the appropriate data types!
Just imagine you have the need to calculate a difference. You would have to split/parse the string, cast it to a numeric type, do the computation and re-format the output.
Descriptive is a word you should only use in connection with presentation layer, reporting and frontend.
Since Keen is not strongly typed, I've noticed it is possible to send data of different types into the same property. For instance, some events may have a property whose value is a String (sent surrounded by quotes), and some whose value is an integer (sent without quotes). In the case of mathematical operations, what is the expected behavior?
Our comparator will only compute mathematical operations on numbers. If you have a property whose values are mixed, the operation will only apply to the numbers, strings will be ignored. You can see the values in your property by running a select_unique query on that property as the target_property, then (if you're using the Explorer) selecting JSON from the drop-down in the top-right. Any values you see there that are surrounded by quotes will be ignored by a mathematical query type (minimum, maximum, median, average, percentile, and sum).
If you are just starting out, and you know you want to be able to do mathematical operations on this property, we recommend making sure that you always send integers as numbers (without quotes). If you really want to keep your dataset clean, you can even start a new collection once you've made sure you are no longer sending any strings.
Yes, you're correct, Keen can accept data of different types as the value for your properties. An example of Keen's lenient data type is that a property such as VisitorID can contain both numbers (ie 14558) or strings (ie "14558").
This is article from the Keen site is useful for seeing where you can check data types: https://keen.io/docs/data-collection/data-modeling-guide-200/#check-for-data-type-mismatch
The title pretty much frames the question. I have not used CHAR in years. Right now, I am reverse-engineering a database that has CHAR all over it, for primary keys, codes, etc.
How about a CHAR(30) column?
Edit:
So the general opinion seems to be that CHAR if perfectly fine for certain things. I, however, think that you can design a database schema that does not have a need for "these certain things", thus not requiring fixed-length strings. With the bit, uniqueidentifier, varchar, and text types, it seems that in a well-normalized schema you get a certain elegance that you don't get when you use encoded string values. Thinking in fixed lenghts, no offense meant, seems to be a relic of the mainframe days (I learned RPG II once myself). I believe it is obsolete, and I did not hear a convincing argument from you claiming otherwise.
I use char(n) for codes, varchar(m) for descriptions. Char(n) seems to result in better performance because data doesn't need to move around when the size of contents change.
Where the nature of the data dictates the length of the field, I use CHAR. Otherwise VARCHAR.
CHARs are still faster for processing than VARCHARs in the DBMS I know well. Their fixed size allow for optimizations that aren't possible with VARCHARs. In addition, the storage requirements are slightly less for CHARS since no length has to be stored, assuming most of the rows need to fully, or near-fully, populate the CHAR column.
This is less of an impact (in terms of percentage) with a CHAR(30) than a CHAR(4).
As to usage, I tend to use CHARs when either:
the fields will generally always be close to or at their maximum length (stock codes, employee IDs, etc); or
the lengths are short (less than 10).
Anywhere else, I use VARCHARs.
I use CHAR when length of the value is fixed. For example we are generating a code or something based on some algorithm which returns the code with the specific fixed lenght lets say 13.
Otherwise, I found VARCHAR better. One more reason to use VARCHAR is that when you get the value back in your application you don't need to trim that value. In the case of CHAR you will get the full length of the column whether the value is filling it fully or not. It would get filled by spaces and you end up trimming every value, and forgetting that would lead to errors.
For PostgreSQL, the documentation states that char() has no advantage in storage space over varchar(); the only difference is that it's blank-padded to the specified length.
Having said that, I still use char(1) or char(3) for one-character or three-character codes. I think that the clarity due to the type specifying what the column should contain provides value, even if there are no storage or performance advantages. And yes, I typically use check constraints or foreign key constraints as well. Apart from those cases, I generally just stick with text rather than using varchar(). Again, this is informed by the database implementation, which automatically switches from inline to out-of-line storage if the value is large enough, which some other database implementations don't do.
Char isn't obsolete, it just should only be used if the length of the field should never vary. In the average database, this would be very few fields mostly some kind of code field like State Abbreviations which are a standard 2 character filed if you use the postal codes. Using Char where the filed length is varaible means that there will be a lot of trimming going on and that is extra, unnecessary work and the database should be refactored.
Is there a term to represent a set of all possible values a variable can assume?
Analogy:
In mathematics a domain of a function is a set of values a function is defined on (function can take as an argument).
Examples:
A variable of type UInt16 can hold values in range [0-65536).
Completion status (represented by a double value) can hold a value in range [0-100].
Gender (represented by an Enum) can hold one of { Male, Female }.
Q:
What is a term to describe all possible values a variable can (contextually) assume?
Basically need a short version of "set of values for a variable". I have seen term type being used to describe such a range, but Type often encompasses other bits of information (e.g. a name, operations, module).
value set
domain
value range
I've also heard "value space" as a term for this.
I would just call it the "range", or "range of values".
Domain would be the math term.
I don't know of programming-specific jargon with that meaning, but "domain" itself seems like a pretty good one...
[EDIT] Read the comments to this, and I actually prefer "range".
I don't know if this is the exact terminology (if it even has one) but I have always referred to it as a range or in the case of enums options.
Range is the proper term, as in "this method will return values within the range of..."; "The expected range of this variable is:..." etc.
For atomic types, the type itself describes the range (e.g. int has a range of -2,147,483,648 to 2,147,483,647).
Anything that is a custom type may or may not have a range because custom types (e.g. struct, class, interface) are composite types that can be made up of atomic or other custom types.
The definition of a type will also vary between different languages.
The long and short of it is generally you will only be able to apply a range to atomic types based on a specific language.
It depends on the type system. In some programming laguages, a "string" can hold a sequence of characters, and an "unsigned int" can only hold positive whole numbers. In others like python, a variable can hold anything at all because it doesn't have a certain type.
Our quants here say it is called a value set. They get paid tons of money to create them so I believe them!
You may think of a variable as containing an element that is a member of a set of numbers.
As such, domain is a good descriptor for the possible values of this set.
Range is also often used in a similar context. Here we talk of the range of a function, as the set of values the function can take on. Since a variable always contains the result of some expression or computation, range clearly makes sense too.
Either is appropriate in the proper context.