This question already has answers here:
What is your alternative name for ID variable in Objective-C?
(6 answers)
Closed 9 years ago.
I am making some improvements in project made by my predecessors on current job. I found property id in NSManagedObject class as shown below:
Also Xcode highlights this property name as id type. Can this cause some problems in future? I mean, does system smart enough to understand that this is a property name? Do I need to rename it through refactor or just let it stay as is?
id is a reserved word in objective-c, do not use any reserved words as property names on an object.
Don't use id in your model prefer uid for example even if the compiler can distinguish the difference it is not a good practice.
Related
This question already has answers here:
What is the difference between Scope_Identity(), Identity(), ##Identity, and Ident_Current()?
(7 answers)
Closed 4 years ago.
I would like to make my UserID column a GUID type and I found these three options. I do not know exactly what is the main difference between them.
I think the best version is NEWSEQUENTIALID().
->##IDENTITY returns the last auto_incremented(identity) value (even if it is created by a trigger/user defined function).
->SCOPE_IDENTITY() returns the last identity value created (that is not created by a trigger or an udf).
->NEWSEQUENTIALID() creates a GUID that is greater than any GUID previously generated by this function on a specified computer since Windows was started. (For more information, see https://learn.microsoft.com/en-us/sql/t-sql/functions/newsequentialid-transact-sql?view=sql-server-2017)
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 4 years ago.
Improve this question
As a developer, a common mistake that I keep on repeating is assuming the data type of a column. I have read multiple articles regarding SQL column naming convention but have not seen any reference regarding data type as part of the column name - specifically for SQL Server.
E.g. Revenue_f for float, Organization_v for varchar, AccountNumber_i for integer and so on.
This must have been thought of already before but I want to know the reason why it is not being used, or an expert's input regarding the matter; pointing me to the right article/documentations will be greatly appreciated.
That is a horrible naming convention. Consider how awful it would be if you need to change AccountNumber to a character datatype. Do you then go back and rename the column and change every single query everywhere? Or do you leave the suffix in your column name even though it is no longer accurate? If you want to know the datatype of a column the ONLY way is to look at the definition of the table.
Also, a single character really is kind of useless. How do you handle nvarchar vs varchar? And what about the scale?
P.S. Even though I wrote an answer I am voting to close this question because it is primarily opinion based and as such is considered off topic for SO.
This question already has an answer here:
Validate Postcode in Access?
(1 answer)
Closed 8 years ago.
I'm trying to validate a UK post code field in MS Access using the LIKE function and I need to be able to allow the possibility that a character be A-Z, 0-9, or simply not be present.
Some postcodes have 1 digit for the first section, others have 2.
So far I have the following:
Like "[A-Z][A-Z,0-9][A-Z,0-9][A-Z,0-9,][ ][0-9][A-Z,0-9][A-Z,0-9]"
However, the third and fourth characters may not even exist in a given post code, how can I handle this?
This is a function which I have used in the past, not sure if it is the best. However I know it work(ed)s. So you might want to give it a try.
http://mikeperris.com/access/VBA-code-validate-UK-postcode.html
The Author of the code uses a RegEx patter to match the post code based on its length. This provides a major advantage of avoiding the use of LIKE.
Provides a simple True, if the postcode is valid or False, if it is invalid.
This question already has answers here:
How to get around the Scala case class limit of 22 fields?
(5 answers)
Closed 8 years ago.
This is a challenge specific to SPARK-SQL and I'm unable to apply two highlighted answers
I'm writing complex data processing logic in SPARK-SQL.
Here is the process I follow ,
Define case class for a table with all attributes.
Register that as table.
Use SQLContext to query the same.
I'm encountering an issue as Scala allows only 22 parameters whereas my table has 50 columns. Only approach I could think of is to break dataset in such a way that it has 22 parameters and combine them later at the end. It does not look like a clean approach. Is there any better approach to this issue ?
Switch to Scala 2.11 and the case class field limit is gone. Release notes. Issue.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Split Function equivalent in tsql?
I have a column that contains data in the form:
CustomerZip::12345||AccountId::1111111||s_Is_Advertiser::True||ManagedBy::3000||CustomerID::5555555||
Does SQL have any sort of built in function to easily parse out this data, or will I have to build my own complicated mess of patindex/substring functions to pull each value into its own field?
I don't believe there is anything built in. Look at the comments posted against your original question.
If this is something you're going to need on a regular basis, consider writing a view.