|
Difference between count(*) and count(column_name)
|
|
|
We might assume that count(*) and count(column_name) will return same result count. But NO, in case of column holds any null values.
Count (*) – returns all values (including nulls and duplicates)
Count (Column_Name) – returns all Non-NULL values(including duplicates)
In the below script we will see how it works. So that it will be easy for us to understand.
create table #tempTable(Name char(1))
insert into #tempTable values("A")
insert into #tempTable values("B")
insert into #tempTable values(Null)
insert into #tempTable values("C")
insert into #tempTable values(Null)
insert into #tempTable values("C")
select COUNT(*) from #tempTable
select COUNT(Name) from #tempTable
drop table #tempTable Output: 6 and 4
The table #temptable has total 6 rows. Count(*) returns all the rows including null/duplicates but where as count(name) returns only 4 rows which includes duplicates("C") but not null values.
If you want to remove the duplicates from count(Name) then use distinct keyword in it.
select COUNT(distinct Name) from #tempTable –-returns 3
|
|
|
|
|
What is managed and unmanaged code in .NET
|
|
|
Manged Code - code which is executed under Common Language Runtime (CLR). Due to this, the code has many benefits like memory management, support of version control, type safety and security. The code which targets CLR and written in .NET framework is a managed code. E.g: C#,VB.NET
Unmanaged code : code which is not executed under .NET runtime (CLR). CLR is does not have control over execution of code.memory management, security and type safety should be taken care by developer. E.g: VB6, C,C++.
managed code typically compiled to Intermediate Language(IL) code where as unmanged code directly compiles to native code.
|
|
|
|
|
|
|
|
|
What are the differences between Azure functions and Azure logic apps
|
|
|
Azure function and Azure logic apps both are serverless workloads. Let's look at a few differences below.
| Azure Functions | Azure logic Apps | | Execute event-driven serverless code functions with an end-to-end development experience | Automate the access and use of data across clouds | | serverless compute services | Serverless workflows | | Code first approached - imperative | Design first - declarative | | Uses App Insights for monitoring | Uses Azure Monitor logs and Azure Portal | | Managed with Rest API and Visual studio | Managed with Azure Portal, Rest API, Visual studio and PowerShell | | Execute locally or in cloud | Run any where | | Lot of binding types and extend your own bindings | Lot of connectors or build your own | | We can call Azure logic apps from Functions | We can call Functions from logic app | | Write code for each activity to execute | In built read made actions(app connectors) available to integrate from the collection |
Based on above comparisons and your requirement factors you can choose any of the service.
|
|
|
|
|
What are the different hosting plans for Azure functions
|
|
|
While creating Azure Functions, we must choose a hosting plan for the App. There are 3 basic plans named App Service Plan(dedicated), Consumption, and Premium plans and all these plans are available in Windows and Linux VM’s.
Let's look at what plan provides which features and based on these features and your needs you can select the right plan.
| Feature/Plan | Consumption | Premium | Dedicated | | Scaling | Automatically based on incoming requests | Automatically with pre-warmed instances so that no delays | Predictive scaling or Manual | | Scale Out Max# instances | Windows - 200
Linux - 100
| Windows - 100
Linux - 20-100 | 10-20 | | Cold start | With Idle scenario, scale goes to 0 and we have latency to scale | With Pre-warming feature there is no latency | NA - function app runs continuously | | Default Plan | Yes | No | No | | VNET connectivity | No | Yes | Yes | | App timeout(Min) | 5 mins | 30 mins | 30 mins | | App time out(Max) | 10 mins | unlimited | unlimited | | Billing | Pay only for the time when App runs | Pay as per runs plus pre warms | Pay as per App Service Plan | | When to consider | - Scale automatically
- Pay only when you run
| - App requires continuous run
- You need more CPU, memory and high GB seconds than consumption plan
- More execution time than consumption plan
- VNET connectivity
| - Want to re-use existing App Service Plan
- Predictive scaling and cost requirements
|
Other than these 3 basic plans, we have App Service Environment(ASE) and Kubernetes isolation plans, do refer Microsoft documentation.
|
|
|
|