In this post, I am sharing a small demonstration to get the random result of your SELECT statement in SQL Server.

We can use NEWID() which creates a unique value type of uniqueidentifier. You just need to ORDER BY your result set using NEWID() and you will get the random result every time.

You should also know about the UUID:

Database Theory: The truth about Universally Unique Identifier – UUID

Create a sample table:

CREATE TABLE tbl_Students
(
	Rno INT PRIMARY KEY
	,STudName VARCHAR(20)
	,ClassName CHAR(1)
)
GO

Insert a few sample records:

INSERT INTO tbl_Students 
VALUES 
(1,'Anvesh','A'),(2,'Neevan','B'),(3,'Toby','C')
,(5,'Roy','A'),(4,'Jenny','B'),(6,'Kaviy','C')
,(7,'Martin','A'),(8,'Laxmi','B'),(9,'Nion','C')
GO

Use NEWID() in ORDER BY to get random results:
I executed below query three times, below you can find three random results.

SELECT *FROM 
tbl_Students
ORDER BY NEWID()
GO

#1
Rno         STudName             ClassName
----------- -------------------- ---------
2           Neevan               B
6           Kaviy                C
1           Anvesh               A
3           Toby                 C
8           Laxmi                B
9           Nion                 C
4           Jenny                B
5           Roy                  A
7           Martin               A

#2
Rno         STudName             ClassName
----------- -------------------- ---------
1           Anvesh               A
2           Neevan               B
8           Laxmi                B
9           Nion                 C
7           Martin               A
4           Jenny                B
6           Kaviy                C
5           Roy                  A
3           Toby                 C

#3
Rno         STudName             ClassName
----------- -------------------- ---------
3           Toby                 C
1           Anvesh               A
6           Kaviy                C
8           Laxmi                B
5           Roy                  A
4           Jenny                B
2           Neevan               B
9           Nion                 C
7           Martin               A

The default nature of PostgreSQL is based on MVCC architecture which managed by different type of ROW versions.
You can read more about MVCC,

What is Multi Version Concurrency Control (MVCC)

Why I have started this article with MVCC because whenever we update data into the table, it creates a new record and marked the old record as an old version or dead tuple.

You can visit UUID related article here,

Database Theory: The truth about Universally Unique Identifier – UUID

PostgreSQL: Working with Universally Unique Identifier – UUID Data type

My problem:

One of our table size is more than 30gb and I got one requirement to add one new column with default UUID data. This table is already loaded by bulk insertion and exclusive lock never work in this situation.

While adding a column with default value requires PostgreSQL to make new versions of all rows, rewritten the entire table – indexes and store them on the disk and during that time Table will be locked.

The Solution should be like:

This task is required to perform on Production report server so it is very much important to take care about everything like: no exclusive lock, within given time frame limit, data should not be fragmented.
I have tried different approaches which are, I am going to share in this article.

Option 1:

Add new column with NULL value, do not assign any default value in ALTER statement.

After adding a new column, we should run different small batches to update the newly created column.

Find out data fragmentation, dead tuples and try to optimize and remove using VACUUM – ANALYZE.

Option 2:

CREATE one new blank table with require all old and new columns.
Create different small batches and move data from Old table to the newly created table.

While transferring the data, populate default value of the new column. (In my case, I have generated UUID on the fly)
ADD all require constraint and indexes on the newly created table.
Stop all the running data insertion queues for a while, drop the old table and rename a new table to require an original table name.

Yet, I am not 100% sure about these approaches, but I have done my task without any locking issue and completed within given time frame.

If you have any other optimized way, Please share your ideas.

The PostgreSQL provides Universally Unique Identifier -UUID data type and related functions.

In the previous post, I shared the truth about Universally Unique Identifier - UUID.
You can visit this article here.

PostgreSQL provides two extensions.

1. uuid-ossp
2. pgcrypto.

You can install above extension using below script.

CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
CREATE EXTENSION IF NOT EXISTS pgcrypto;

I am using pgcrypto extension for generating an UUID.

Below is a small demonstration:

Generate UUID using gen_random_uuid():

SELECT gen_random_uuid();

Create a sample table with UUID Data type:

CREATE TABLE tbl_UUIDSample
(  
   MyUUID UUID PRIMARY KEY DEFAULT gen_random_uuid()
   ,Name TEXT   
);

Insert sample data:

INSERT INTO tbl_UUIDSample (Name)
VALUES
('Anvesh'),('Martin')
,('Roy'),('Jenny')
,('Ronic'),('Monika');

The Result:

SELECT *FROM tbl_UUIDSample;

I am Sharing an important theory for all Database Architects and Designers.

We are following a common practice for creating a sequential, unique number for a database system.

The best practice is to create a primary integer key for every table which represents the tuples.
But you should also know about UUID.
You can visit this article on The truth about Primary Key.

What is UUID and How it generates Unique Number?

UUID – Universally Unique Identifier has also stand as a unique string.

A UUID is a 128-bit number, and it used to identify different type of entities uniquely.
The computation of the UUID is quick and easy to generate an ID which can be reasonably assumed to be universally unique.

The UUID is globally unique because it contains a unique combination of the network address, the timestamp of the transaction and other component details.
The network address and timestamp of the transaction are enough to ensure uniqueness.

Example, The standard form of UUID. It is total of 32 digits and representing the 128 bits.

c0acbc88-9q0b-4hq3-cc6u-8pp9er188a33

Why we require UUID?

When we are working in the distributed environment system, we need UUID which identifies the integrated data from the different systems.

For example,
We have two systems, System A and System B. Now I want to import some data from System A to System B without changing an ID of the source system. System B has already set of stored IDs which might conflict with System A IDs.

The UUID solves the above problem.

If the system is not online, the offline user also can generate a UUID at the client side for few operations.

A UUID always unique for all the systems which reside in a distributed environment.

For Example,
System A inserts a record with ID 10 and at the same time System B also inserts a record with ID 10.
Now, this is a collision.
The UUID solves this problem.

If the system is accessed by multiple threads, each thread has to wait for new IDs.
A UUID also solve this problem because it does not depend on the previously generated key.

We can generate trillions of UUID in a year and it has very less chance of duplication.

If we recreate a Database or Table, again sequential ID starts from 1. In this kind of situations, we can use UUID.

Other limitations:

The index fragmentation is one of the major drawbacks of using UUID random keys.

We should not use UUID as a Primary key of a table. Still, I would suggest you create an integer sequential primary key and create a separate column for UUID.