Stairway to Data, Level 3: Strings
Character-handling in SQL is not particularly straightforward, and confusion about collation and character encoding is a common cause of problems with searching, joining, and sorting.
Character-handling in SQL is not particularly straightforward, and confusion about collation and character encoding is a common cause of problems with searching, joining, and sorting.
Joe Celko discusses Nominal, Categorical, Absolute, Ordinal and Rank scales. These are the weakest scales we can use, starting with the weakest.
Joe Celko introduces more powerful scales such as Interval, Log interval and ratio scales; before moving on to conversions, punctuation and units. Finally he gives guidelines as to how best to use scales in a database.
Joe discusses how to deal with the kinds of encoding schemes, how to use them and how to design them. He discusses Enumeration, Measurement, Abbreviation and Algorithmic categories
Joe discusses Hierarchical, Vector and Concatenation encoding before rounding up with general guidelines for designing encoding schemes.
Before you start to think about your database schema or tables, you need to consider your data: the type of data it is, the scale you use for values. It needs to be unique, precise and unambiguous. Then you need to name it in such a way that it can be generally understood. Joe Celko explains...
A clear understanding of SQL Data Types and domains is a fundamental requirement for the Database Developer, but it is not elementary. If you select the most appropriate data type, it can sidestep a variety of errors. Furthermore, if you then define the data domains as exactly as possible via constraints, you can catch a variety of those problems that would otherwise bedevil the work of the application programmer.
There are several types of tables, each with their special requirements for rules and integrity constraints. Whatever the requirement, table-level constraints will ensure that the rules are enforced and data integrity is maintained.
Having described tables, Joe Celko explains how to make them work together as a database and touches on what Entity Relationships and Views are.
Joe Celko tackles the subject of the Stored Procedure and its place in database design. What he writes is food for thought, even for experienced database developers.
If you’ve been watching AI roll through the data community and thinking, “this seems...
By Arun Sirpal
Not every production incident is a database in RECOVERY_PENDING or a corrupted event (like...
It is Friday, the queries are running, and nobody is watching the bill. That...
Comments posted to this topic are about the item SQL Art, Part 4: Happy...
Hi All I am trying to find 'bad' characters that users might type in....
Comments posted to this topic are about the item Extreme DAX: Take your Power...
I set up a few users on my SQL Server 2022 instance.
CREATE LOGIN User1 WITH PASSWORD = 'Demo12#1' CREATE USER User1 FOR LOGIN User1 GO CREATE LOGIN User2 WITH PASSWORD = 'Demo12#2' CREATE USER User2 FOR LOGIN User2 GO CREATE LOGIN User3 WITH PASSWORD = 'Demo12#3' CREATE USER User3 FOR LOGIN User3 GOI then created a schema that one of them owned. Under this schema, I added a table with some data.
CREATE SCHEMA MySchema AUTHORIZATION User1
GO
CREATE TABLE Myschema.MyTable(myid INT)
GO
INSERT MySchema.MyTable
(
myid
)
VALUES
(1), (2), (3)
GO
SELECT * FROM MySchema.MyTable
GO
I granted rights and verified that User2 could access this table.
GRANT SELECT ON Myschema.MyTable TO User2 GO SETUSER 'USER2' GO SELECT * FROM MySchema.MyTable GOThis worked. Now, I move this schema to a new user.
ALTER AUTHORIZATION ON SCHEMA::Myschema TO User3; GOWhat happens with this code?
SETUSER 'USER2' GO SELECT * FROM MySchema.MyTable GOSee possible answers