├── DBMS
    ├── 0.Links
    ├── 11.Master-Slave
    ├── 10.CAP theorem
    ├── 7.Types of DB
    ├── project_db
    ├── 9.Scaling
    ├── 6.NO SQL
    ├── 8.Clustering, Partitioning, Sharding
    ├── 3.Normalisation
    ├── 4.Transactions
    ├── 5.Indexing
    ├── 2.SQL_
    └── 1.Basics
├── OOPS
    ├── a.out
    ├── static.cpp
    ├── destructor.cpp
    ├── Class_obj.cpp
    ├── const.cpp
    ├── Polymorphism.cpp
    ├── Inheritance.cpp
    ├── 1.Basics
    ├── copyconst.cpp
    ├── 2.The 4 pillars
    └── 1.basics_cpp
├── OS
    ├── OS_Full_Notes.pdf
    └── Links
├── CN
    ├── Links
    └── pts
├── Puzzles
├── Resume-grills
├── Interview-HPE
├── Interview-Greenlight
└── HR-questions


/DBMS/0.Links:
--------------------------------------------------------------------------------
1 | - Playlist: https://youtu.be/eYpXCdvKwEQ


--------------------------------------------------------------------------------
/OOPS/a.out:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Shree8622/Placement-Prep/HEAD/OOPS/a.out


--------------------------------------------------------------------------------
/OS/OS_Full_Notes.pdf:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Shree8622/Placement-Prep/HEAD/OS/OS_Full_Notes.pdf


--------------------------------------------------------------------------------
/CN/Links:
--------------------------------------------------------------------------------
1 | - Love Babbar roadmap: https://whimsical.com/networking-cheatsheet-by-love-babbar-FcLExFDezehhfsbDPfZDBv
2 | 


--------------------------------------------------------------------------------
/OS/Links:
--------------------------------------------------------------------------------
1 | - Links
2 |     Mutex vs Semaphore : https://www.geeksforgeeks.org/mutex-vs-semaphore/
3 |     Playlist: https://youtu.be/_TpOHMCODXo


--------------------------------------------------------------------------------
/OOPS/static.cpp:
--------------------------------------------------------------------------------
 1 | #include<iostream>
 2 | using namespace std;
 3 | 
 4 | class A
 5 | {
 6 |     public:
 7 |     static int val;
 8 |     int b;
 9 |     
10 |     static void func()
11 |     {
12 |         cout<<val<<endl;
13 |     }
14 | };
15 | int A::val = 2;
16 | int main()
17 | {   
18 |     // A::func();
19 |     A a,b;
20 |     
21 |     // You can see that both the members of the class share the same memory address for static variables
22 |     cout<<a.val<<" "<<&a.val<<" "<<&b.val<<endl;
23 | }


--------------------------------------------------------------------------------
/Puzzles:
--------------------------------------------------------------------------------
 1 | - Links
 2 |     - GFG
 3 |         https://www.geeksforgeeks.org/top-20-puzzles-commonly-asked-during-sde-interviews/
 4 |     - Aptitude
 5 |         https://www.firstnaukri.com/career-guidance/65-logical-reasoning-questions-and-answers-for-freshers
 6 |     - Youtube
 7 |         - https://youtu.be/j51KlMTFuhU
 8 |         - https://youtu.be/4cm1DowaQCA
 9 |         - https://youtu.be/r5a5n0SHkw0
10 |         - https://youtu.be/nRNVVumluQs
11 |         - https://youtu.be/JzyrbnFOaZQ
12 |         - https://youtu.be/s7NtLUQ4X4k


--------------------------------------------------------------------------------
/OOPS/destructor.cpp:
--------------------------------------------------------------------------------
 1 | #include<iostream>
 2 | #include<string.h>
 3 | using namespace std;
 4 | 
 5 | class Destructor
 6 | {
 7 |     public:
 8 |     int val;
 9 |     ~Destructor()
10 |     {
11 |         cout<<this->val<<" ";
12 |         cout<<"Destructor is called"<<endl;
13 |     }
14 | };
15 | 
16 | 
17 | int main()
18 | {
19 |      Destructor d;
20 |      d.val=1;
21 | 
22 |      Destructor *dynamic = new Destructor();
23 |     dynamic->val = -1;
24 | 
25 |     delete dynamic; //if commented, the destructor is only called once
26 |     // observe the order in which destructor is called
27 | }


--------------------------------------------------------------------------------
/DBMS/11.Master-Slave:
--------------------------------------------------------------------------------
 1 | - Master-Slave architecture
 2 |     - Requests --> Load balancer --> DB
 3 |     - Single point of failure 
 4 |         A single server is handling the requests and if it fails, then whole system fails
 5 |     - Master node => handles all write operations
 6 |     - Replica nodes => handles only read operations and replicate from the master node
 7 | 
 8 | - How replications happen?
 9 |     - Asynchronus
10 |         - Independently updates happen from master to slave 
11 |         - Delay is accepted for a small amount of time
12 |     - Synchronous
13 |         - Updates it whenever there's an update 
14 |     
15 | - Advantages
16 |     - backup
17 |     - scale-out read operations
18 |     - increasing availability


--------------------------------------------------------------------------------
/OOPS/Class_obj.cpp:
--------------------------------------------------------------------------------
 1 | #include<iostream>
 2 | using namespace std;
 3 | 
 4 | class PaddingExample
 5 | {
 6 |     public:
 7 |     int marks;
 8 |     char a;
 9 |     PaddingExample(int a)
10 |     {
11 |         this->marks = 1;
12 |     }
13 |         
14 | };
15 | class PaddingEx2
16 | {
17 |     public:
18 |     int marks;
19 |     char a,b,c,d,e;
20 | };
21 | 
22 | int main()
23 | {
24 |     PaddingExample s1(1);
25 |     // If u think it should print 5; read about padding and greedy alignment
26 |     cout<<sizeof(s1.a)<< " "<< sizeof(s1.marks)<<endl;  //prints 1 4 
27 |     cout<<sizeof(s1)<<endl; // prints 8
28 | 
29 |     PaddingEx2 s2;
30 |     cout<<sizeof(s2)<<endl;// prints 12 instead of 9
31 | 
32 |     // Calling a copy constructor example
33 |    
34 | }


--------------------------------------------------------------------------------
/OOPS/const.cpp:
--------------------------------------------------------------------------------
 1 | #include<iostream>
 2 | using namespace std;
 3 | 
 4 | int func(int *y)
 5 | {
 6 |     return *y;
 7 | }
 8 | int func1(const int *y)
 9 | {
10 |     return *y;
11 | }
12 | class A
13 | {
14 |     public:
15 |     void constfunc() const
16 |     {
17 |         cout<<"Im a constant function"<<endl;
18 |     }
19 |     void randfunc()
20 |     {
21 |         cout<<"Im a random function"<<endl;
22 |     }
23 | };
24 | int main()
25 | {
26 |     const int i = 2;
27 |     
28 |     int x = 2;
29 |     const int *ptr = &x;
30 |     //cout<<func(ptr);<<endl;//doesnt work
31 |     cout<< func1(ptr)<<endl; //works
32 | 
33 |     // A constant object can call only constant functions
34 |     const A obj;
35 |     obj.constfunc();
36 |     // obj.randfunc(); //doesnt work
37 | 
38 | }


--------------------------------------------------------------------------------
/OOPS/Polymorphism.cpp:
--------------------------------------------------------------------------------
 1 | #include<iostream>
 2 | using namespace std;
 3 | 
 4 | class FakeInt
 5 | {
 6 |     public:
 7 |     int val;
 8 | 
 9 |     // Overloading + operator to subtract values
10 |     int operator+(FakeInt& op2)
11 |     {
12 |         return op2.val-this->val;
13 |     }   
14 | };
15 | 
16 | class Animal
17 | {
18 |     public:
19 |         void speak()
20 |         {
21 |             cout<<"Make some noise!"<<endl;
22 |         }
23 | };
24 | class Dog : public Animal
25 | {
26 |     public:
27 |     void speak()
28 |     {
29 |         cout<<"I bark!"<<endl;
30 |     }
31 | }; 
32 | int main()
33 | {
34 |     // Operator overloading 101
35 |     FakeInt a,b;
36 |     a.val=2;b.val=3;
37 | 
38 |     cout<<b+a<<endl;
39 |     cout<<a+b<<endl;
40 | 
41 |     // Function overriding
42 |     Dog d1;
43 |     Animal a1;
44 |     a1.speak();
45 |     d1.speak(); // local function overrides the inherited function
46 |     d1.Animal::speak();
47 | }


--------------------------------------------------------------------------------
/Resume-grills:
--------------------------------------------------------------------------------
 1 | - Deep knowledge about things mentioned in the resume
 2 | - Skills:
 3 |     - Python
 4 |         - dynamically typed
 5 |             - The association of a variable type is done during execution
 6 |         - interpreted
 7 |             - Runs with an interpreter. The translate decode and execute happen parallely
 8 |         - PEP 8 Python Enhancement Proposal
 9 |             - Style and the syntactic decisions about python
10 |         - docstring
11 |             '''
12 |             ''' -> docstrings
13 |         - Pass by reference always:- actual value is passed
14 |         - *args and **kwargs
15 |             arguments and keyword arguments
16 |     - Flask
17 |         - based on wsgi (web server gateway interface)
18 |         - jinja2 template engine
19 | - Quantum:
20 |     - BB84 protocol
21 |     - Qubit
22 |     - Differences, shors algo, optimisation
23 | 
24 | -Project:
25 |     - CLI: Click
26 |         - not argparse coz it guesses what is option and what is argument
27 |     - ML: ARIMA models; Time series prediction models


--------------------------------------------------------------------------------
/OOPS/Inheritance.cpp:
--------------------------------------------------------------------------------
 1 | #include<iostream>
 2 | using namespace std;
 3 | 
 4 | class Parent 
 5 | {
 6 |     private:
 7 |         int var;
 8 |     protected:
 9 |         int var1;
10 |     public:
11 |         int pub_var;
12 | };
13 | 
14 | class Child1 : public Parent
15 | {
16 |     int child_var;
17 |     public:
18 |     int getvar1()
19 |     {
20 |         return this->var1;
21 |     }
22 | };
23 | 
24 | class Child2 : protected Parent
25 | {
26 |     int child_var;
27 |     public:
28 |     int getvar1()
29 |     {
30 |         return this->var1;
31 |     }
32 | };
33 | 
34 | class Multi_lvl_child : public Child1
35 | {
36 |     void func()
37 |     {
38 |         cout<<"Multi-level child"<<endl;
39 |     }
40 | }
41 | 
42 | class Multiple_inh_child: public Child1,public Child2:
43 | {
44 |     void func()
45 |     {
46 |         cout<<"Im a multiple inheritance"<<endl;
47 |     }
48 | }
49 | int main()
50 | {
51 |     Child1 c;
52 |     cout<<c.pub_var<<endl; //Works 
53 |     //cout<<c.var1<<endl; //Doesnt work
54 |     cout<<c.getvar1()<<endl; //Works 
55 | 
56 |     Child2 c1;
57 |     cout<<c1.pub_var<<endl; //Doesnt work.. becomes protected
58 | }


--------------------------------------------------------------------------------
/DBMS/10.CAP theorem:
--------------------------------------------------------------------------------
 1 | - CAP
 2 |     - Consistency
 3 |     - Availability
 4 |     - Partition tolerence
 5 | 
 6 | - Theorem states that all 3 properties cant exist together in real world.
 7 |   Tradeoff between consistency and Availability when there's a partition
 8 | 
 9 | - CA
10 |     - No partition
11 |     - Not fault tolerant
12 |     - deploy it on one node, using replication we can try to solve fault tolerance
13 | - CP
14 |     - Whenever there's a partiton, then read requests from the node are stopped until a    consistent replica of the db instance is obtained from the server
15 |       Ex: Mongo DB
16 |       Banking systems should be consistent always
17 | - AP
18 |     - eventually consistent
19 |     - after the replicated data is updated to the read servers, consistency is regained
20 |     - used in cases where buisness logics support inconsistency in read for a given period of time
21 |     Ex: Cassandra, Amazon Dynamo DB
22 | 
23 | - BASE properties of db [social networking based dbs]
24 |     - Basically Available
25 |     - Soft state 
26 |         - there can be many changes in the state of the db even if there are no interactions from the user. {Increase in likes overnight,,, ;>}
27 |     - Eventually consistent 


--------------------------------------------------------------------------------
/DBMS/7.Types of DB:
--------------------------------------------------------------------------------
 1 | - Relational DB
 2 |     - Relational model is used
 3 |     - Issues:
 4 |         - Scalability
 5 |         - Data becomes huge, system becomes more complex
 6 |     - Ex: MySQL - matured, support is enormous
 7 | - No SQL
 8 |     - Refer to doc 6
 9 | - Object Oriented DB
10 |     - Not that popular
11 |     - Modelling of the scenario in an object oriented approach is necessary
12 |     - Everything is defined and stored in terms of an object
13 |     - handles -> ID of object
14 |     - Stores structured Data
15 |     - Methods are used to interact between objects
16 |     Ex: Object DB, Gemstone
17 | 
18 | - Hierarchial DB    
19 |     - Ex: Family tree
20 |     - A parent table relation is always present [concrete hierarchy]
21 |     - Parent can ahve multiple childs, but a child can have only one parent
22 |     - Since disk storage is also a hierarchial strucure, can be used as physical models
23 |     - Adv: 
24 |         - Easy to use
25 |         - Adding and deleting will be Easy
26 |     - Disadv
27 |         - Cant descibe complex relationships
28 |         - Requires top to bottom sequential searching
29 |         - traversal are very slow
30 | 
31 |     Ex: IBM IMS
32 | 
33 | - Network DB
34 |     - Organised in graph type structure
35 |     - child can have multiple parents
36 |     - Maintainenece is tedious
37 |     Ex: Integrated Data Store,IDBMS, Turbo Image
38 | 


--------------------------------------------------------------------------------
/DBMS/project_db:
--------------------------------------------------------------------------------
 1 | -"info":  these are my internship project based questions which I asked myself
 2 | 
 3 | - what is the need of the database?
 4 |     - to store triggers and actions at a centralised location
 5 |     - would be used in reconstruction of the logstash configuration file
 6 |     - Centralised datarepo is required to store the user manual triggers
 7 | - sqlite3 
 8 |  -  mysql vs sqlite3 
 9 |     - mysql is server based whereas sqlite is not
10 |     - smaller (library is in KB whereas 600MB in mysql)
11 |     - easy setup and ease of use for testing
12 |  - issues of sqlite: 
13 |     - user management (multiple user logins)
14 |     - weaker security 
15 |     - less efficient concurrency control 
16 | - why not no-sql
17 |     - Use case for no-sql is diff
18 |         - Fast retrievals allowing redundancy to seep in
19 |         - horizontal scaling to support distributed system executions
20 |         - sharding to improvise the way data is chunked into different pieces
21 |     - We store parameter vals to generate a logstash conf file not updated frequently [We arent storing sensor data but the threshs]
22 |     - If required, for a given set of system groups, the relations can be sharded
23 | 
24 | - why not distributed database arch(a basic requirement for no sql db)?
25 |     - would lead to time latencies which would increase the response time to the occuring fault in the system
26 | - Keys in the designed db:
27 |     - Trigger 
28 |         SK& CK & PK = {name,parameter_name}
29 |     - Action 
30 |         SK & CK & PK = {name}


--------------------------------------------------------------------------------
/CN/pts:
--------------------------------------------------------------------------------
 1 | - Some IMP pts
 2 |   - NIC: Network Interface Controller
 3 |   - MAC address: Media Access Control Address assigned to a NIC which is used for network communications in a given network
 4 |   - NAS: Network Attached Storage server that holds files that can be accessed by the computer connected on a LAN
 5 |   - NTFS: New technology file system
 6 |   - packet switching: A packet can take different paths to reach the same destination from a given source
 7 |   - ICANN: Intl Association for Assigned names and Numbers
 8 |   - DHCP: Dynamic Host Configuration Protocol
 9 |     - Runs at application layer at TCP/IP stack
10 |     - Used to assign dynamic IP addr to all hosts in a netowrk
11 |     - Steps:
12 |       - Discover
13 |       - Offer
14 |       - Request
15 |       - Ack
16 |   - PSTN: Public Switched Telephone Network
17 |   - Topologies:
18 |     - Mesh: Kn graph, every node is connected to every other node
19 |     - Star: One central host is connected to all the other hosts
20 |     - Ring: Circular connectivity
21 |     - Tree: Bus + Star
22 |     - Bus: Single common line connecting all the systems
23 | 
24 |   - Devices at each OSI layer:
25 |     - Physical: network hubs, cabling, repeaters, network adapters or modems
26 |     - Data link: NIC and switch
27 |       - MAC[Media Access Control] layer: flow control and multiplexing for device transmissions over network
28 |       - LLC[Logical link control] layer : identifies line protocols and provides flow,error control over physical medium
29 |     - Network: Router
30 |     - Transport: Gateway
31 |     
32 |   - CDN: Content Delivery Network
33 | 


--------------------------------------------------------------------------------
/OOPS/1.Basics:
--------------------------------------------------------------------------------
 1 | - Tell me about OOPS
 2 |     Oops is a programming paradigm which relies on the concepts of classes and objects (Basically all problems are broken down and represented in entities like objects) 
 3 |     It has 4 main properties: Abstraction, Encapsulation,Polymorphism, Inheritance
 4 | 
 5 | - What is a programming paradigm? (Follow up)
 6 |     The different ways/styles in which a given program/programming language can be organised
 7 |     - Imperative 
 8 |     - Logical 
 9 |     - Functional 
10 |     - Object-oriented
11 | 
12 | - Polymorphism:
13 |     Representation of same object in multiple ways
14 |     Types:
15 |     - Function overriding(dynamic)
16 |     - Function overloading(static)
17 |     
18 |     Real life ex:- A person at different times (Office,Home,Party)
19 | 
20 | - Inheritance:
21 |     An object acquires certain properties from its parent class
22 |     Types:- 
23 |     - single level
24 |     - hierarchial
25 |     - multi level
26 |     - multiple (supported oly by cpp)
27 |     - hybrid (supported oly by cpp)
28 | 
29 |     Real life ex:- Humans (eat,breathe,sleep from parents)
30 | 
31 | - Encapsulation
32 |     Wrapping up of data members and member functions into one single entity
33 | 
34 |     Real life ex:- School bag
35 | 
36 | - Abstaction 
37 |     Hiding of non essential features of a given object and displaying the required/necessary elements
38 | 
39 |     Real life ex:- ATM machine
40 | 
41 | ----------------------Surprises------------------------------
42 | - Cpp allows multiple inheritance hence doesnt have super keyword
43 | 
44 | 
45 | 
46 | - 'this' operator is used with '->' in cpp whereas '.' in java


--------------------------------------------------------------------------------
/OOPS/copyconst.cpp:
--------------------------------------------------------------------------------
 1 | #include<iostream>
 2 | #include<string.h>
 3 | using namespace std;
 4 | 
 5 | class CpyConst
 6 | {
 7 |     public:
 8 |     int a;
 9 |     CpyConst()
10 |     {
11 |         this->a=1;
12 |     }
13 |     CpyConst(CpyConst& obj)
14 |     {
15 |         cout<<"Copy constructor is called"<<endl;
16 |         this->a = obj.a;
17 |     }
18 | };
19 | 
20 | class Hero
21 | {
22 |     public:
23 |     char *name;
24 | };
25 | 
26 | class DeepHero
27 | {
28 |     public:
29 |     char *name;
30 |     DeepHero()
31 |     {
32 | 
33 |     }
34 |     DeepHero(DeepHero& a)
35 |     {
36 |         this->name = new char[strlen(a.name)+1];
37 |         strcpy(name,a.name);
38 |     }
39 | };
40 | int main()
41 | {
42 |      CpyConst obja;
43 | 
44 |     CpyConst objb(obja);
45 |     cout<<objb.a<<endl;
46 |     
47 |     Hero h1;
48 |     char name[7] = "babbar";
49 |     h1.name = name;
50 | 
51 |     Hero h2(h1); //using default copy constructor
52 |     
53 |     // printing normal values
54 |     cout<<h1.name<<endl;
55 |     cout<<h2.name<<endl;
56 | 
57 |     h1.name[0]= 'G';
58 | 
59 |     // See the output.. both names are changed but we only hero1's name is Gabbar
60 |     cout<<h1.name<<endl;
61 |     cout<<h2.name<<endl;
62 | 
63 |     DeepHero d1;
64 |     char dname[7] = "babbar";
65 |     d1.name = dname;
66 | 
67 |     DeepHero d2(d1); //using default copy constructor
68 |     
69 |     // printing normal values
70 |     cout<<d1.name<<endl;
71 |     cout<<d2.name<<endl;
72 | 
73 |     d1.name[0]= 'G';
74 | 
75 |     // Now we have two different strings so its not affected
76 |     cout<<d1.name<<endl;
77 |     cout<<d2.name<<endl;
78 | }


--------------------------------------------------------------------------------
/Interview-HPE:
--------------------------------------------------------------------------------
 1 | - Technical:
 2 |     - Tell me about yourself (After 3 mins of awk silence and searching for my resume in their software)
 3 |     - Tell us about your CTY project that you worked on in the internship
 4 |     - Which language do u code with?
 5 |     - Write merge sort code on the board
 6 |     - What is the complexity analysis of the code?
 7 |     - Which sorting algorithm is best? Why?
 8 |     - Are you comfortable with networking concepts?
 9 |         - If you enter 'google.com' in your browser, what will happen?
10 |     - Did you use databases in your projects? What is the diff b/w SQL and no-SQL?
11 |     - Which is better? Compiler or Interpreter? Why?
12 |     - How do you pass Command line arguments?
13 |     - Why did you go for click package and not argparse in your project?
14 |     - Any questions for us?
15 |         - I asked: 
16 |             - Is HPE investing in quantum computing?
17 |             - What are the divisions at HPE?
18 | 
19 | - Managerial:
20 |     - Introduce yourself
21 |     - (Saw my CIRQuIT mention in the resume) How did you get into this club? Why did u go?
22 |     - You have intrests in different domains, what is the main path/domain that 
23 |       you want to work on right now?
24 |     - What do you want to do as a employee at HPE?
25 |     - I see you in leadership roles in your resume, what is one difficulty that you've faced until now?
26 |     - What is a significant problem that you faced in your life until now?
27 | 
28 | - HR:
29 |     - Introduce yourself
30 |     - What do you think HPE does(Products that they offer n stuff)?
31 |     - What do you want to add into the culture of HPE?
32 |     - Do you want to do masters?
33 |     - Why HPE? How does the intrests align?  


--------------------------------------------------------------------------------
/DBMS/9.Scaling:
--------------------------------------------------------------------------------
 1 | - DB Scalability patterns
 2 |     - Problems
 3 |         - API Latency
 4 | 
 5 |     - Pattern 1
 6 |         - Query optimisation
 7 |             - Introduce redundancy
 8 |             - Denormalise some relations
 9 |         - Connection Pool implementation
10 |             - Cache DB connections
11 |             - Reduce db connects for each threads
12 |             - auth issues are handled only once
13 |             
14 |     - Pattern 2 
15 |         - Vertical scaling
16 |         - Pocket friendly till a given point
17 |     
18 |     - Pattern 3 {Command Query Responsiblity Segregation [CQRS]}
19 |         - Replica is created for a given server
20 |         - Write and read requests are maintained differently
21 |         - Replicas are introduced which handle reads and replicate with a givne Latency
22 |         - Primary server serves write requests
23 |     
24 |     - Pattern 4 {Multi query replication}
25 |         - All machines can act as primary and replica
26 |         - data is divided into logical data rings
27 |         - Circular replication
28 |         - Any write request can be given to any server
29 |     
30 |     - Pattern 5 {Partitoning data by functionality}
31 |         - reconstruct the database such that the schemas are designed based on the functionality
32 |         - Application layer in backend should be able to break down a given request into induvidual requests and then coombine all of the results to give a final combined output back to the system
33 | 
34 |     - Pattern 6 {Horizontal scaling / Scaling out}
35 |         - Sharding is applied
36 |         - Locality of data must be present 
37 |         - Ex: Indian cab data is useless if its stored in US server.. 
38 | 
39 |     -  Pattern 7 {Data centre wise partition}
40 |         - distributing data across data centers in each continent
41 |         - Replication is used for disaster recovery
42 |         - Always maintain availability
43 | 


--------------------------------------------------------------------------------
/DBMS/6.NO SQL:
--------------------------------------------------------------------------------
 1 | - No SQL {Not Only SQL}
 2 |     - Advantages:
 3 |         - Flexible schema:
 4 |             Ex: Null vals need not be stored
 5 |             {"Name":"A", Location:"Tmk"},{"Name":"B"}
 6 |             - Location attr is null for second record automatically!
 7 |         - Horizontal scaling
 8 |             - parts of db can stored seperately ny using sharding* and replication*
 9 |         - High availabiltiy
10 |             - Replica sets are maintained
11 |             - No loss in services
12 |         - Easy insert and read ops
13 |             - since joins arent req, read ops are vary fast in no sql db
14 |             - Rule is that "Data that should be accessed together is stored together"
15 |     - Use cases:
16 |         - Fast dev
17 |         - Huge volumes of Data
18 |         - Reqs of scale-out architecture
19 |         - Used in paradigms like micro-services
20 |     - Types:
21 |         - Key-value stores
22 |             - {Key,value} pairs are stored in a doc
23 |             - use effiecient indexing mechanisms to find the document records 
24 |             Ex: Amazon Dynamo DB 
25 |         - Column based 
26 |             - Insertion is dem slow
27 |             - Read is dem fast
28 |             - used in analytics
29 |             Ex: Cassandra
30 |         - Document based
31 |             - stores data similar to the format of JSON objects
32 |             - used widely in cloud industry* 
33 |             [can get grilled about this :< ]
34 |             - supports ACID
35 |             Ex: Mongo DB, Couch DB 
36 |         - Graph based stores
37 |             - Representation; Nodes(entities) and edges(relationships)
38 |             - Overcomes JOIN overheads found in SQL 
39 |             Ex: NEOJ
40 |     - Disadv;
41 |         - Redundancy(More memory)
42 |         - Update and Delete are costly
43 |         - Doesnt support ACID
44 |         - doesnt support consistency constraints 
45 |     
46 |             


--------------------------------------------------------------------------------
/Interview-Greenlight:
--------------------------------------------------------------------------------
 1 | - Total rounds = 3
 2 | - Round 1: Technical round-1 
 3 |   - Introduce yourelf
 4 |   - After mentioning about my position at CIRQuIT, was asked to explain Quanutm Computing to a layman
 5 |   - Coding Question : Reverse Nodes in k-Group
 6 |     - link: https://leetcode.com/problems/reverse-nodes-in-k-group/
 7 |     - A detailed solution with code involoving a long discussion on edge cases
 8 |     - Time complexity analysis
 9 | 
10 |   - Any questions about the company?
11 | - Round 2: Technical round-2
12 |   - Introduce yourself
13 |   - Coding question: Word ladder
14 |     - link: https://leetcode.com/problems/word-ladder/
15 |     - A bit of confusion in the start about the approach
16 |     - Discussed about the representation of the current array of words in a graph.. criteria for an edge,etc
17 |     - Type of traversal chosen,etc
18 |     - Final code was accepted but asked for an optimised approach
19 |     - Time complexity analysis
20 | 
21 | At this point.. I thought I'll be rejected as others knew the solutions beforehand for the leetcode hard questions and they breezed through
22 | Somehow I made it to round 3
23 | 
24 | - Round 3: Managerial round
25 |   - Introduce yourself (Was asked more on the family,schooling,etc)
26 |   - Why choose Greenlight?
27 |   - Where do you see yourself in 5 years?
28 |   - Will you go for masters?
29 |   - Lets say you have an optimised code than your teammate and you know for sure it is better and can contribute to the cause. How will you handle it if:
30 |     - Your teammate is a fresher
31 |     - Your teammate has 4-5 yrs experience in the industry
32 |   - How do you work under highly supervised teams? (If the mentor is highly intrested in knowing what youre upto)
33 |   
34 | - Round 4: HR
35 |   - Introduce yourself
36 |   - How were your previous interviews.. say a line about each round
37 |   - What is your main source of motivation?
38 |   - Given four entites [College,Course,Teacher,Student], design a DB, I want to see the steps you follow to design a database
39 |   - Did you have a look on the products of greenlight?
40 |   - Give some examples from your journey relevant to these words
41 |     - Brave
42 |     - Teamwork
43 |     - Leader
44 |   - Any questions for me? 
45 |     (I asked about the role and the main motive of the company... discussion went on for 20 mins only on this question)
46 | 


--------------------------------------------------------------------------------
/HR-questions:
--------------------------------------------------------------------------------
 1 | - Tell me about yourself
 2 |     - Greet,Name,Edn bg
 3 |     - Exp,skills,achievements
 4 |     - Justify why you're the right fit for the role
 5 | 
 6 |     - Answer: 
 7 |         - I am Shreenidhi T L and Im pursuing my Bachelor of Engg at RV College of Engg under Info Science and Engg branch. 
 8 |         - Im the Vice-president at Coding Club RVCE and vertical head for Quantum Communication at CIRQuIT (which is a Centre of Excellence for Quantum Computing at RVCE)  [10s]
 9 |         - I really like working on backend components like configuring APIs, designing databases and problem statements on automation. I enjoyed coding with cpp and python I was kindof amazed by how readability affects the usage criteria for a language. I have given seminars on basics in Quantum and taken up jobs as a part-time tutor for python. [20s]
10 |         - I've been curious about computer fundamentals since my schooling days and good at adapting to newer tech-stacks and exploring opensource tools. My hobbies are playing badminton and practicing Veena  [5s]
11 | 
12 | - Tell me about your strengths
13 |     - Self motivated
14 |     - Quickly adapt and try to understand the requirements in a situation
15 |     - I remain curious to open ended questions and I spend a lot of time exploring new things
16 |     - I understand the values of teamspirit and would always try to build on working with new ideas with people
17 | 
18 | - Tell me about your weaknessess
19 |     - I tend to take up too much of reponsiblities at times and struggle to manage time and health at times; for example - SRM incident
20 |     I have made it a routine to revisit my priorities and rethink about them 
21 |     - I don't enjoy public speaking or interactions with large crowds. 
22 |     But I've made it my best efforts to give a few lectures at college and take up some oppurtunities to improve on that
23 | 
24 | - Questions to ask
25 |     - Is HPE invested in entering the quantum industry?
26 |     - What is the main aim of the new scalable AI product?
27 |         - Will it be a IaaS or PaaS ?
28 |     - What are the main divisions in the company?
29 |     - How are these datasets collected for the AI models? Opensource?
30 |         - Kinds of data regulations required as you are the providers for multiple clients?
31 |     - Job description?
32 |     - Anything like an annual sport event in HPE? 


--------------------------------------------------------------------------------
/DBMS/8.Clustering, Partitioning, Sharding:
--------------------------------------------------------------------------------
 1 | - Clustering 
 2 |     - Horizontal scaling has a limitation 
 3 |     - Replica sets: Same db is copied to multiple servers. A collection of all this is     called one cluster
 4 |     - Why?
 5 |         - Redundancy!
 6 |             - Availability should be maintained
 7 |             - multiple servers are maintained for the service Availability
 8 |         - Load balancing
 9 |         - High Availability
10 |     - CDN(Content Delivery Networks)
11 |         - reduces latency
12 |         - instead of a central server handling all requests, a geographically nearer server stores the required data and transmits it to the user
13 |         - Growth of large online streaming platforms, Network Service Providers are deploying their own content distribution Networks
14 | 
15 |         - CDN vs Cloud: 
16 |             - CDN provides content delivery from the origin server and replicates the data held in the main servers
17 |             - Cloud is more on service based things: IaaS,SaaS,PaaS, which are connected to the network and provide services to the public
18 | 
19 | - Partitioning 
20 |     - Problem:
21 |         - When handling large amt of data and huge no of requests, a single system will not have all the resources to sustain it
22 |         - Therefore its better to make it a distributed system
23 |     
24 |     - Solution:
25 |         - Scale-up: Increase the system hardware 
26 |         - Replica-set(Clustering): 
27 |             - Master-Slave architecture:
28 |                 - Updates occur to a master and are propogated to the slaves
29 |                 - The slave system holds the same data as of the amster and it can serve for read requests
30 |         - Partitioning (Scale-out):
31 |             - New node is added and the data is also partitioned into different groups
32 |             - Types:
33 |                 - Vertical Partitioning [column wise]
34 |                 - Horizontal Partitioning [row wise]
35 | - Sharding 
36 |     - Technique to partition data horizontally
37 |     - [1 to 100] in one server and [101 to 200] in another server
38 |     - Both servers are independent
39 |     - Requires a routing layer in app layer to route the request to a particular shard.
40 |     - Cons:
41 |         - Routing layer is required
42 |         - Non uniformity is formed [One particular shard will have more requests]
43 |             - Solution: Reshard the db


--------------------------------------------------------------------------------
/DBMS/3.Normalisation:
--------------------------------------------------------------------------------
 1 | - Functional Dep
 2 |     A -> B 
 3 |     
 4 |     A => detereminant
 5 |     B => dependent
 6 |     - It means A can determine B
 7 |     - Types: 
 8 |         - Trivial 
 9 |             Ex: AB -> A 
10 |             - Dependent is the subset of detereminant
11 |         - Non-Trivial
12 |             Ex: AB -> C
13 |     - Rules (Armstrong's axioms)
14 |         Consider A -> B 
15 |         - Reflexive
16 |             If B is subset of A; A-> B
17 |         - Augmentation
18 |             If X -> Y 
19 |                 then we can say AX -> AY 
20 |         - Transitivity
21 |             If A -> B and B -> C
22 |                 then A->C 
23 | - Why normalisation?
24 |     To reduce redundancy
25 | - So what if we have redundant data?
26 |     - Redundant data introduces 3 anomalies
27 |         - Insertion
28 |             certain values are unknown at this point of time 
29 |             [Student hasnt enrolled to branch but has paid a fee, we are storing student and branch details together]
30 |             - cant insert a branch which doesnt have students.. [lets say a new branch waiting for admission]
31 |         - deletion
32 |             Ex: deleting last student enrolled to a branch.. 
33 |                 branch is gayab in db after u delete this entry nw
34 |         - updation
35 |             Ex: HOD name is stored with all student records and his value is changed
36 | - What happens in normalisation?
37 |     table is decomposed until it implies with SRP (Single Responsiblity Principle)
38 | - Normal forms
39 |     - 1 NF
40 |         - Atomic value in each attr
41 |         - No multivalued attr 
42 |         Ex: PhNo=>{120392103,129312023} cant happen!
43 |     - 2 NF  
44 |         - No partial dependency
45 |         - All non prime attr should be fully dependent on PK
46 |             Ex: R(A,B,C) PK = {AB}, then a FD A->C cant exist
47 |                 As AB is a PK, there can be 4 cases on how a tuple is recognised
48 | 
49 |                 A       B
50 |                 val_a   val_b
51 |                 val_a   NULL  
52 |                 NULL    val_b => in this case, if A-> C exists, NULL determines something.. thts nt possible
53 |     - 3 NF
54 |         - No Transitivity
55 |         - Non prime shouldn't determine a non prime 
56 |         Ex: R(A,B,C) FD: A->B,B->C PK={A}  
57 |             Here due to Transitivity, A->C is possile..
58 |     
59 |     - BCNF
60 |         Given A->B, A should be super key
61 |         B cant contain any prime attributes!
62 |     - 4 NF  
63 |         - Multi-dependent variables arent kept in relation
64 |     - 5 NF  
65 |         - Lossless decomposition  [TBD]


--------------------------------------------------------------------------------
/DBMS/4.Transactions:
--------------------------------------------------------------------------------
 1 | - Transaction
 2 |     - A unit of work done against the DB.
 3 |       A Sequence of operations with the DB
 4 |     - If the unit of wrk has failed in between, the db instance is rolled back to the previous instance
 5 | - ACID properties
 6 |     - Atomicity
 7 |         Either all changes are done in DB or none are reflected
 8 |         If a transaction is sucessful, its fine
 9 |         if it fails, then instance is rolled back 
10 |     - Consistency
11 |         All integrity constraints are maintaned after transactions
12 |     - Isolation
13 |         There shouldn't be any influence of a given transaction over other transactions 
14 |     - Durability
15 |         After transaction, the change in the db state should persist permanently, even if there is a system failure
16 | - States of transaction
17 |     - Active state: Read/Write ops are happening
18 |     - Partially committed: Read/Write changes are saved in a buffer of main memory
19 |     - Commit state: db.commit() => all changes are done and valid => Changed instance
20 |     - Terminated: Final state 
21 |         If successful, instance 2 is saved else original instance
22 | - How is atomicity achieved?
23 |     - Shadow copy scheme
24 |         - A copy of current state of db is loaded to RAM
25 |         - Changes are made to the state
26 |         - new copy is said to be commited when the db pointer is written to the disk and the ptr is updated to the new copy 
27 |         => commit is notified only when the pointer is updated to the new instance 
28 |         => write to the db pointer is assumed to be atomic 
29 |         * Inefficient
30 |     - Log based recovery
31 |         - stored under stable storage 
32 |         - stable storage => has atomic read writes; durable to system crashes
33 |         - Types
34 |             - Deffered DB modification
35 |                 - Logs are written until the commit state is attained
36 |                 - Changes are written only when changes are committed
37 |                 - If system crashed before commit() stage, logs are ignored
38 |                 - If system fails at writing commits stage, the commit is performed again.
39 |             - Immediate DB modification
40 |                 - Log along with modification is done for every operations
41 |                 Ex: <T0,start>
42 |                     <T0,A,100,200> A is changed from 100 to 200
43 |                     <T0,B,1,-1> B is changed from 1 to -1
44 |                     <T0,commit> 
45 |                 - If failed before commit, old value is written to the db instance using logs (100=>A,1=>B) and the operation is performed again
46 |     - Checkpoint based recovery 
47 |         - All transactions before a given checkpoint is said to be valid / complete
48 |         - The transactions are rolled back into the checkpoint if any kind of failure occurs


--------------------------------------------------------------------------------
/OOPS/2.The 4 pillars:
--------------------------------------------------------------------------------
 1 | - Encapsulation
 2 |     - Data members[states] and member functions[methods] are wrapped in a single entity
 3 |     - A class implements Encapsulation
 4 |     - Fully encapsulated class  
 5 |         - All members are private
 6 |     - Adv?
 7 |         - Information hiding 
 8 |         - we cant access the members of a class outside the class if we dont write getter and setter functions
 9 |         - Code reusability
10 |         - Unit testing
11 | 
12 | - Inheritance
13 |     - A class inherits/ acquires data members and member functions from another class
14 |     - Parent class --> Child class
15 |     - Types:
16 |         - Single 
17 |             A -> B
18 |         - Multi level
19 |             A -> B -> C
20 |         - Hierarchial
21 |             A -> {B,C,D}
22 |         - Multiple
23 |             {A,B} -> C
24 |         - Hybrid inheritance
25 |             Multi-level + Multiple inheritance
26 |     - Ambiguity
27 |         - Multiple inheritance causes this
28 |         - consider {A,B} both have a function named abc()
29 |         - now if class C inherits both A and B,
30 |             it should use scope resolution operator to refer to the function implementation that it is referring to.
31 |         - Solution: virtual class
32 |             - there's no duplication of implementation in a hybrid inheritance
33 |             Ex: A -> {B,C} -> D 
34 |             now B,C have to be declared virtual to make sure D doesnt have multiple implementations of a function in A
35 | 
36 | - Polymorphism*
37 |     - single object has Multiple forms
38 |     - Types:
39 |         - compiletime
40 |             - function overloading
41 |                 - differing by parameter [type and number]
42 |                 - default parameters
43 |             - operator overloading [only in cpp]
44 |                 - Ex: {+} add and string conatenation
45 |                 - Operators that cant be overloaded are  
46 |                     . (dot)  
47 |                     ::(scope resolution) 
48 |                     ?:(ternary)   
49 |                     sizeof() 
50 |         - runtime
51 |             - function overriding
52 | 
53 | - Abstraction
54 |     - Implementation hiding
55 |     - Showing only required Information
56 |     - Using access modifiers
57 |     - Advantages:
58 |         - Control over who can change what
59 |         - Increases reusability
60 |         - Avoids duplication
61 | 
62 |     - Interfaces    
63 |         - SAM Interfaces
64 |         - Interfaces dont 'may' contain implementation of the functions
65 |         - Interfaces v/s Abstract classes
66 |             - If no implementation is known, Interfaces
67 |             - If it is partially known, Abstract classes 
68 |     - Abstract classes  
69 |         - cant have objects only refernces
70 |         - contain atleast one abstract method
71 |          


--------------------------------------------------------------------------------
/DBMS/5.Indexing:
--------------------------------------------------------------------------------
 1 | - Indexing
 2 |     - Problem: Performance optimisation
 3 |         - Each relation will have a PK and all the tuples will be sorted with respect to that PK
 4 |         - For searching any tuple, we can apply linear.. nah binary search [log(n) Time complexity bruh]
 5 |         - But if the search space is too large, then the access is slow..
 6 | 
 7 |     - Solution 
 8 |         - A data structure called Index is used
 9 |         - It stores {key,base pointer} values for a set of uniformly spaced keys.
10 |         For ex:
11 |             Records: 1,2,3,4....11,12,13,....,21,22,23.... 
12 |             Index table:
13 |                 {base:1,Bp:0x1, base:11,Bp:0xb,..}
14 |     
15 |     - Types:
16 |         - Primary Indexing (Clustering indexing)
17 |             - Applied where the data file is sequentially sorted 
18 |             - A search key can be PK or a non prime attr
19 |             - Dense Index 
20 |                 - every search key value is present in the index 
21 |                 -  in case multiple records are present for that particular search key, the first record location is stored
22 |             - Sparse index
23 |                 - An index that has only some search key values
24 |                 - helps in finding some block which contains the search key
25 | 
26 |             - Sorted based on key attr:
27 |                 - Usually Sparse indexing is used with this
28 |                 - as we know that the records are sorted using the PK/CK attrs 
29 |             - Sorted based on non-key attr:
30 |                 - Dense indexing is used
31 |                 - Every unique value is indexed
32 |                 - Ex: Records=>{1*,1,1,2*,2,2,2,3*,3,4*,4}
33 |                       Indexes stored =>{1*,2*,3*,4*}
34 |             - Multi level indexing
35 |                 - used in large files
36 |                 Ex: Records=>{1,2,3,...1000,1001,1002,.....2000..}
37 |                     Index lvl-1 =>{[1-100],[101-200],[201-300]..} => Secondary index 
38 |                     Index lvl-2 =>{[1-1000],[1001-2000]} => Primary index 
39 |         - Secondary indexing
40 |             - Applied on unsorted data files or
41 |                 Ex: R(USN,Hometown)
42 |                     When u sort based on USN which is PK, the hometown attr is completely unsorted and secondary indexing helps us to optimise finding records in situations like this 
43 | 
44 |             - Dense indexing is used 
45 |             - If search key values repeat in the relation, then all the entries are stored in a linked list format
46 |             Ex: Position   0 1  2  3  4  5 6 7  8
47 |                 Records=> {1,99,55,22,1,43,2,90,87..}
48 |                 Indexes stored =>
49 |                 [
50 |                     { 1 => [0,4] } // 1 is present at position 0 and 4 
51 |                     { 2 => [6] }
52 |                     { 22 => [3] }
53 |                     { 43 => [5]}
54 |                     { 55 => [2]}
55 |                     { 87 => [8]}
56 |                     { 90 => [7]}
57 |                     { 99 => [1]}
58 |                 ]
59 |             - Now binary search can be applied on these indexes 


--------------------------------------------------------------------------------
/OOPS/1.basics_cpp:
--------------------------------------------------------------------------------
 1 | - Class
 2 |     - logical construct of an object
 3 |     - User defined datatype  
 4 | 
 5 | - Empty class will have size of 1 B
 6 | 
 7 | - Objects
 8 |     - instance of a Class
 9 |     - stored in heap memory
10 |     - creating an object => new keyword
11 |     - accessing the object
12 |         - dot operator
13 |         ref(stored in stack) --> object(heap)
14 |         Student 0xff              (at 0xff) {USN,name}
15 | 
16 | - Access modifiers
17 |     - private 
18 |     - public
19 |     - protected
20 |     - default
21 | 
22 | - getter and setter functions
23 |     - used to get and set values into properties of a class [which are private]
24 | 
25 | - Padding
26 |     - Every datatype has alignment requirements
27 |     - Processing word length will be 4 bytes on a 32 bit machine; So if processor calls a fetch, 4B will be fetched
28 |     - So to optimise this, during allocation objects are given space in multiples of 4. 
29 |     - So even if u have an object that occupies 5B, the memory allocated to it will be 8B.
30 |     
31 | - Greedy allocation of memory
32 |     - No odd byte boundaries are made
33 |     - Allocates all members of a structure in a way such that minimum padding is achieved
34 |     
35 | - Constructor
36 |     - default Constructor
37 |         - no return type
38 |         - this keyword is used to refer to the current object
39 |     - parameterised Constructor 
40 |     - copy Constructor
41 |         - an object is passed into the Constructor
42 |         - deep copy can be done manually using copy constructor 
43 |         - cant pass by value. should use pass by ref 
44 |     - overloading
45 |         - different parameter types and number of parameters
46 |     - calling a const from another Constructor
47 |     Ex:
48 |         Const()
49 |         {
50 |             this(1,2,3)
51 |         }
52 |         Const(int a,int b,int c)
53 |         {
54 |             this.val=a+b+c;
55 |         }
56 | - Deep vs Shallow copy
57 |     - default copy constructor uses shallow copy
58 |     - vaiables like character arrays or any references to heap will be copied from the initial object
59 |     - A seperate copy must be made so that a change in the first object doesnt result in change of the second object
60 | 
61 | - Destructor
62 |     - For a statically generated object, destrcutor is called automatically
63 |     - For a dynamically created object destructor has to be called manually{CPP}
64 |     - Use a '~' operator for destrcutor {CPP}
65 |     - finalise() method works like a destrcutor for an object. It is defined inside the given class {Java}
66 | 
67 | - Static 
68 |     - static variable doesnt belong to a given object
69 |     - belongs to a class
70 |     - static functions can only access static variables
71 | 
72 | - Wrapper Class 
73 |     - classes written for primitive datatypes such as int,float,etc
74 |         - Integer for int 
75 |         - Float for float
76 |     - Advantage is that we get to use spl functions and we can use pass by ref only for Objects
77 |     
78 | - final keyword
79 |     - variable's value cant be modified 
80 |         - Exception when the variable is a non-primitive, you can make changes to that object's values
81 |     - function cant be overrided 
82 |     - Class cant be inherited
83 | - friend class [only in cpp] 
84 |     - A friend class is offered spl priviliges to acces the private and protected members and functions
85 |     - It can be a global function / member of another class also


--------------------------------------------------------------------------------
/DBMS/2.SQL_:
--------------------------------------------------------------------------------
  1 | - SQL: Structured Query Language
  2 | - RDBMS: Relational DBMS:- MySQL,MS Access,etc
  3 | 
  4 | - Ops:
  5 |     - CRUD
  6 | - Datatypes:
  7 |     - VARCHAR vs CHAR:
  8 |         VARCHAR(255) Dynamically increases the size of the char array upto 255 B
  9 |         CHAR preallocates 255 B of memory to the variable
 10 |     - ENUM
 11 |         One of the preset values will be entered 
 12 |         Ex: Genre {Horror, Comedy, Action, Historic} => movie can have only one of these
 13 |     - SET
 14 |         One or many of the preset values
 15 |         Ex: Question tags {Array,DP,Hashmap} => question can have mulitple of these
 16 |     - JSON [Advanced datatypes]
 17 | - Commands
 18 |     - DDL {Data definition Language}
 19 |         - CREATE TABLE table_name(attr1 datatype,attr2 datatype)
 20 |         - ALTER TABLE 
 21 |         - DROP
 22 |         - TRUNCATE
 23 |         - RENAME
 24 |     - DRL {Data Retreival Language}
 25 |         - SELECT
 26 |     - DML {Data manipulation Language}
 27 |         - INSERT
 28 |         - UPDATE
 29 |             ON UPDATE CASCADE
 30 |                 - lets say u changed the id of a student from 51 to 01
 31 |                 - now in the child table that value will be changed 
 32 |         - DELETE
 33 |             ON DELETE CASCADE
 34 |                 - Deletion of an entry from the parent deletes the child entry
 35 |             ON DELETE SET NULL  
 36 |                 - Deletion will update child table iwth a null value
 37 |             
 38 |     - DCL {Data Control Language}
 39 |         - GRANT
 40 |         - REVOKE
 41 |     - TCL {Transaction Control Language}
 42 |         - START TRANSACTION
 43 |         - COMMIT 
 44 |         - ROLLBACK
 45 |         - SAVEPOINT
 46 | - Spl commands
 47 |     - AUTO_INCREMENT => automatic increment for a value 
 48 |         Ex: CREATE TABLE me(id INT NOT NULL AUTO_INCREMENT, name VARCHAR)
 49 | 
 50 | - DQL stuff
 51 |     - Can we use select without 'from' ?
 52 |         Yes. Using dual tables. Basically the db system creates temporary table to implement whatever operation you pass into select
 53 |          
 54 |         Ex: SELECT 5+5;
 55 |             SELECT now(); -> returns server time
 56 |             SELECT lcase('ABCDabcd') => 'abcdabcd'
 57 |             SELECT ucase('ABCDabcd') => 'ABCDABCD'
 58 |     
 59 |     - Patterns searching
 60 |         we use 'LIKE' command for this
 61 |         - pattern specifiers: 
 62 |             - % => for any length of letters
 63 |             - _ => for only one character
 64 |             - * => for any number of characters 'ab*' accepts 'abababab'
 65 |     - Sorting
 66 |         ORDER BY (Attr name)
 67 |             - ORDER BY {attr} ASC => ascending
 68 |             - ORDER BY {atte} DESC => descending
 69 |     -  Aggregation functions 
 70 |         They apply some math/logical functions on the data records in the given attr column
 71 |         - COUNT
 72 |         - MIN
 73 |         - MAX
 74 |         - SUM
 75 |     - GROUP BY.. HAVING
 76 |         - used for conditional group by clause
 77 |         - filters elements from the formed groups.. 
 78 |         unlike WHERE => this filters from the whole table
 79 | - DDL 
 80 |     - CHECK constraint
 81 |         - CONSTRAINT constraint_name CHECK(condn)
 82 |     - DEFAULT
 83 |         - sets a default value
 84 | - DML
 85 |     - REPLACE
 86 |         - Inserts entry into the table if the entry isnt present
 87 |         or else replaces the entry 
 88 |         [with the same PK]
 89 |         Syntax: REPLACE INTO table_name (attr1,attr2) values (val1,val2)
 90 | - JOINS*
 91 |     - INNER JOIN    
 92 |         - Only tuples which have a entry in both the tables will be present in the resultant table {tables should have a common attr}
 93 |         - The final table will have all the attributes from table1,table2
 94 |         Syntax: SELECT col_list from table1 INNER JOIN table2 ON CONDITION 
 95 |     
 96 |     - OUTER JOIN    
 97 |         - LEFT JOIN 
 98 |             - Has all the tuples from the left table + the tuples from right table that satisfy the given condition 
 99 |             Syntax: SELECT col_list from table1 LEFT JOIN table2 ON CONDITION
100 |         - RIGHT JOIN 
101 |             - Has all the tuples from the right table + the tuples from the left table which match the given condition
102 |             Syntax: SELECT col_list from table1 RIGHT JOIN table2 ON CONDITION
103 |         - FULL JOIN
104 |             LEFT JOIN U RIGHT JOIN 
105 |         - CROSS JOIN    
106 |             - Cartesian product of both relations
107 |         - Self JOIN 
108 |             Ex: Employee manages employee 
109 |             Syntax: SELECT e1.id,e2.id,e2.name from Employee as e1 INNER JOIN Employee as e2 where e1.mgr_id = e2.id 
110 |             => Considering e1 has a attr mgr_id which is the id of the manager
111 |     - Can we use join without using JOIN keyword? 
112 |         Yes. Use ',' in the from part in select 
113 |         Ex: SELECT * FROM Employee as e, Client as c where e.client_id = c.id 
114 | - SET OPERATIONS
115 |     * Only applicable if both the relations have the same attributes (same number and same names and types)
116 |     * Used to concat one or more SELECT statements
117 |     - UNION 
118 |     - INTERSECTION 
119 |         - emulated
120 |         Syntax: SELECT DISTINCT id from T1 INNER JOIN T2 using(id)
121 |     - MINUS
122 |         - emulated
123 |         T1 - T2
124 |         Syntax: select id from T1 LEFT JOIN T2 where T2.id IS NULL;
125 | 
126 | - Sub queries (Nested queries)
127 |     SELECT * FROM t1 WHERE t1.id in (SELECT * FROM t2 where location like 'tumkur'); 
128 |     {The inner query isnt dependent on the table used in the outer query}
129 | - Correlated nested queries
130 |     SELECT * FROM t1 as t WHERE EXISTS (SELECT * from t2 where location like 'tumkur' AND t2.income = t.salary);
131 |     {The inner query is dependent on the relation present in the outer query}
132 | - SQL views 
133 |     Syntax: CREATE VIEW view_name AS SELECT a1,a2 from t1;


--------------------------------------------------------------------------------
/DBMS/1.Basics:
--------------------------------------------------------------------------------
  1 | - Data
  2 |     - Collections of raw figurines 
  3 | - Information
  4 |     - Processed data which gives some sense to the representation of data
  5 | 
  6 | - File system vs DBMS
  7 |     - redundancy and inconsistency
  8 |         - bank DB, lets say savings account has address attr and later a current account is added
  9 |           which also has a address attr. Update on either causes an inconsistency
 10 |         - both address attrs are stored seperately: wastage of disk space
 11 |     - difficult to access data  
 12 |         - sql vs request based prgrams for retrieval
 13 |         - different formats
 14 |     - Data isolation
 15 |         - diff formats
 16 |     - Integrity probs
 17 |         - adding a new constraint for a val, INT,LIMIT,etc is tough
 18 |     - Atomicity
 19 |         - spl processes / code which has to execute completely without a context switch
 20 |     - concurrent- access    
 21 |         - resolving multiple client requests
 22 |         - locks have to be implemented manually
 23 |     - Security
 24 |         - rights: admin priviliges and spl user reqs, access permissions can be given
 25 | 
 26 | - ABSTRACTION
 27 |     - main goal of abstraction is to hide the irrelevant details of a system in the perspective of a given user
 28 |     - Each user will get his/her own abstract view of data relevant to his participation in the given domain of the DB
 29 | - Achieved through 3 schema architecture
 30 |     - What is schema? 
 31 |         - A skeleton which provides information about how data is organised in the database
 32 |     - 3 schema architecture
 33 |         - Physical level
 34 |             - Defines parameters of data which define how data is stored
 35 |             - Data structure format, Compression formats, Hashing algos used etc
 36 |         - Conceptual/logical level
 37 |             - What data is stored?
 38 |             - Maps the existing domain elements that have to be stored into the db format
 39 |             - Has representations of interactions in the real world domain
 40 |                 - Entities
 41 |                 - Relationships
 42 |                 - Constraints
 43 |         - View level (also called subschema)
 44 |             - Has a defined view schema which contains elements in which that particular user group is intrested in
 45 |             - Optimises queries (addition and deletion of data)
 46 |             - Secures what parts of data are visible to a given user group
 47 |         - Mappings
 48 |             - Physical to logical
 49 |                 - achieves physical data independence
 50 |                 - any changes in the physical schema dont affect the logical schema
 51 |                 - the mapping can be updated in case of a change for optimisation / other purposes
 52 |             - Logical to view
 53 |                 - achieves logical data independence
 54 |                 - changes in this level doesnt affect the views at the view level (unless and until the changes happen to an element that the view contains)
 55 | - Instance of a DB  
 56 |     - Snapshot of a database at a given instance 
 57 |     - Captures the changes of the transactions that are happening to the database
 58 |     - The instances can be reversed if the given transactions are reversed to the current instance
 59 | - Data models 
 60 |     - Deals with how to design the given data at logical level
 61 | - Languages
 62 |     - DDL: Data Definition Languages
 63 |     - DML: Data Manipulation Languages
 64 |     - both are provided by sql
 65 |     - Query language: A part of DML that serves the CRUD operations from the database and used to define consistency Constraints
 66 | - Connectors: JDBC and ODBC
 67 | - DBMS App architecture
 68 |     - T1 architecture: client,server,DB on the same device
 69 |     - T2 architecture: client is connected to the server through a network, db is on the server recieves query directly from client app
 70 |     - T3 architecture: app client requests a app server which talks to the db; app server and db are located remotely 
 71 | 
 72 | 
 73 | - Relational models
 74 |     - Data is represented in tables
 75 |     - degree od table: total number of attributes
 76 |     - cardinality of table: total number of tuples
 77 | 
 78 | - Types of DB? Graph based?
 79 | 
 80 | - Keys
 81 |     - Super key 
 82 |         Any P and C of attr that uniquely identifies a tuple {AB,ABCD,ABE,AC}
 83 |     - Candidate key
 84 |         Minimum subset from superkey that uniquely identifies a tuple (Attrs arent repreated if they dont add information) {AB,ABE,AC}
 85 |     - Primary key
 86 |         A chosen value from CK set that has minimum number of attrs {AB/AC}
 87 |     - Alternate key
 88 |         CK - PK
 89 |     - Foreign key
 90 |         It is a PK of a relation [Parent table] that is referenced from a child table
 91 |         Handles and creates Relationships in between tables
 92 |     - Composite key
 93 |         PK having multple attrs
 94 |     - Compound key 
 95 |         PK formed using 2 or more FK
 96 |     - Surrogate key*
 97 |         integer values added for each tuples when two relations which dont have same/common PK
 98 |         can be used as PK
 99 | -Integrity Constraints
100 |     - During CRUD ops these constraints should be maintained
101 |     - Domain constraints 
102 |         - Control the types and conditional formats of values that reside in the db {EX: Ph no has to be 10 digits and has to be digits!}
103 |     - Entity constraint 
104 |         - PK cant be NULL
105 |         - Every tuple should be uniquely identifiable 
106 |     - Referntial constraint
107 |         - Insert constraint:
108 |             If the value entered to the ref attr isnt present in the parent table, then the constraint fails
109 |         - Delete constraint 
110 |             A value in the parent table cant be deleted if it has a referncing tuple in the child table. Can be resolved using 3 methods:
111 |                 - ON DELETE CASCADE: 
112 |                     deletes all values in the child table that refernece the tuple to bed deleted
113 |                 - ON DELETE NULL:
114 |                     replaces the values in the child table with NULL 
115 |                 - default: reject the delete request
116 | - Key constraints 
117 |     - NOT NULL : Value cant be NULL 
118 |     - UNIQUE : All the entries in the attr must be unique 
119 |     - DEFAULT : Set a default value for an attribute entry in the relation
120 |     - CHECK : Numerical limits and constraints 
121 |     - PRIMARY KEY
122 |     - FOREIGN KEY


--------------------------------------------------------------------------------