Using named arguments in JavaScript functions

Normally, a JavaScript function takes an list of arguments, with the order of each argument predetermined. As an example, the parseInt() function takes two arguments, a string representing a number, and the radix of that number. You need to specify those in exactly that order, first a string, then the number, or at the very least, just the first argument. However, ponder a function where you wish to specify only the second argument, or both of them in arbitrary order - the deficiency of the JavaScript arguments model prohibits this. In this tutorial, I'll teach you how to modify JavaScript functions to accept named arguments, with which you can specify in any order, as named arguments don't rely on order, but instead their name when passing into functions.
JavaScript functions do not natively support naming arguments, so the simplest way to simulate this functionality is via object literals. Let me illustrate with a custom parseInt() function that can accept its two arguments in any order:
JavaScript Function with Named Arguments
// Define function to take one "argument", which is in fact an object:
function fnParseInt( oArg ){ 
return parseInt( oArg.number, oArg.radix );
}

// Which you then call like this (pass in an object literal):
fnParseInt( { number : 'afy', radix : 36 } );
The key to the above is passing in an object literal as the function's sole parameter instead of separate, "authentic" parameter(s). Now, this is a pretty useless example, but it illustrates my point of creating a function that can accept arguments in any order and via a more intuitive name:value format. Such functions are much more robust than standard ones, not to mention user friendly in cases where the function takes on a lot of parameters.

Difference between Views & Materialized views in Oracle

Difference between Views & Materialized views

Materialized views are disk based and update periodically base upon the query definition.

Views are virtual only and run the query definition each time they are accessed.

Views evaluate the data in the tables underlying the view definition at the time the view is queried. It is a logical view of your tables, with no data stored anywhere else. The upside of a view is that it will always return the latest data to you. The downside of a view is that its performance depends on how good a select statement the view is based on. If the select statement used by the view joins many tables, or uses joins based on non-indexed columns, the view could perform poorly.

Materialized views are similar to regular views, in that they are a logical view of your data (based on a select statement), however, the underlying query resultset has been saved to a table. The upside of this is that when you query a materialized view, you are querying a table, which may also be indexed. In addition, because all the joins have been resolved at materialized view refresh time, you pay the price of the join once (or as often as you refresh your materialized view), rather than each time you select from the materialized view. In addition, with query rewrite enabled, Oracle can optimize a query that selects from the source of your materialized view in such a way that it instead reads from your materialized view. In situations where you create materialized views as forms of aggregate tables, or as copies of frequently executed queries, this can greatly speed up the response time of your end user application. The downside though is that the data you get back from the materialized view is only as up to date as the last time the materialized view has been refreshed.

Materialized views can be set to refresh manually, on a set schedule, or based on the database detecting a change in data from one of the underlying tables. Materialized views can be incrementally updated by combining them with materialized view logs, which act as change data capture sources on the underlying tables.

Materialized views are most often used in data warehousing / business intelligence applications where querying large fact tables with thousands of millions of rows would result in query response times that resulted in an unusable application

Difference between HAVING CLAUSE & WHERE CLAUSE in Oracle

SQL - Difference between HAVING CLAUSE & WHERE CLAUSE

1. HAVING specifies a search condition for a group or an aggregate function used in SELECT statement. The WHERE clause specifies the criteria which individual records must meet to be selected by a query. It can be used without the GROUP BY clause. The HAVING clause cannot be used without the GROUP BY clause.

2. The WHERE clause selects rows before grouping. The HAVING clause selects rows after grouping.

3. The WHERE clause cannot contain aggregate functions. The HAVING clause can contain aggregate functions