Posterous
Daniele is using Posterous to post everything online. Shouldn't you?
Unknown35
 

Daniel’strae

Is cuma cá mhinice a théann tú ar strae; is é is tábhachtaí gurb áil leat do bhealach a aimsiú arís.

Vi servono idee sul layout dei bottoni?

http://www.cssbuttons.net/examples.php
Alcuni buoni esempi (spiegati) di come realizzare bottoni personalizzati con css e immagini.
Gli esempi non sono tantissimi però...

Loading mentions Retweet
Filed under  //   css layout  
Posted June 26, 2009
// 0 Comments

free open-source SQL full-text search engine SPHINX

http://www.sphinxsearch.com/

Loading mentions Retweet
Posted June 25, 2009
// 0 Comments

Ho ricevuto una telefonata magica da un cliente 'PALA'.

lui: Non mi ricordo come si cambia la pasuord della posta
io: Allora, nel menù Impostazioni clicca su Account, poi su Cambia Password
lui: Fatto, ora c'è una pagina con 3 campi, 'pasuord attuale', 'nuova pasuord', 'conferma nuova pasuord', cosa devo fare???
io: SPARATI

Loading mentions Retweet
Posted June 25, 2009
// 0 Comments

Does limiting a query to one record improve performance

Will limiting a query to one result record, improve performance in a large(ish) MySQL table if the table only has one matching result?

for example

 select * from people where name = "Re0sless" limit 1

if there is only one record with that name? and what about if name was the primary key/ set to unique? and is it worth updating the query or will the gain be minimal?

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


If the column has

a unique index: no, it's no faster

a non-unique index: maybe, because it will prevent sending any additional rows beyond the first matched, if any exist

no index: sometimes

  • if 1 or more rows match the query, yes, because the full table scan will be halted after the first row is matched.
  • if no rows match the query, no, because it will need to complete a full table scan

Loading mentions Retweet
Posted June 23, 2009
// 0 Comments

Random data generator for data testing

http://www.generatedata.com

Loading mentions Retweet
Posted June 23, 2009
// 0 Comments

Postgresql index operator (optimization of LIKE queryes)

General LIKE optimization:

CREATE INDEX $index_name
  ON $table_name
  USING btree
  (lower($col_name)  varchar_pattern_ops);

The lower() function is called to avoid the case-sensitive search of the LIKE operator (becose the case-insensitive, ILIKE, cant use index, so we simply assume the col in lower-case during the query)

Hacking LIKE to act as ILIKE with indexes:

SELECT email, nickname FROM users WHERE lower(nickname) LIKE 'E%'

This will use the



11.8. Operator Classes

An index definition may specify an operator class for each column of an index.

CREATE INDEX name ON table (column opclass [, ...]);

The operator class identifies the operators to be used by the index for that column. For example, a B-tree index on the type int4 would use the int4_ops class; this operator class includes comparison functions for values of type int4. In practice the default operator class for the column's data type is usually sufficient. The main point of having operator classes is that for some data types, there could be more than one meaningful index behavior. For example, we might want to sort a complex-number data type either by absolute value or by real part. We could do this by defining two operator classes for the data type and then selecting the proper class when making an index.

There are also some built-in operator classes besides the default ones:

  • The operator classes text_pattern_ops, varchar_pattern_ops, bpchar_pattern_ops, and name_pattern_ops support B-tree indexes on the types text, varchar, char, and name, respectively. The difference from the default operator classes is that the values are compared strictly character by character rather than according to the locale-specific collation rules. This makes these operator classes suitable for use by queries involving pattern matching expressions (LIKE or POSIX regular expressions) when the server does not use the standard "C" locale. As an example, you might index a varchar column like this:

    CREATE INDEX test_index ON test_table (col varchar_pattern_ops);

    Note that you should also create an index with the default operator class if you want queries involving ordinary comparisons to use an index. Such queries cannot use the xxx_pattern_ops operator classes. It is allowed to create multiple indexes on the same column with different operator classes. If you do use the C locale, you do not need the xxx_pattern_ops operator classes, because an index with the default operator class is usable for pattern-matching queries in the C locale.

 

The following query shows all defined operator classes:

SELECT am.amname AS index_method,
opc.opcname AS opclass_name

FROM pg_am am, pg_opclass opc
WHERE opc.opcamid = am.oid
ORDER BY index_method, opclass_name;

It can be extended to show all the operators included in each class:

SELECT am.amname AS index_method,
opc.opcname AS opclass_name,
opr.oid::regoperator AS opclass_operator
FROM pg_am am, pg_opclass opc, pg_amop amop, pg_operator opr
WHERE opc.opcamid = am.oid AND

amop.amopclaid = opc.oid AND
amop.amopopr = opr.oid
ORDER BY index_method, opclass_name, opclass_operator;

Loading mentions Retweet
Posted June 22, 2009
// 0 Comments

Postgresql Explainer of Explain plan (ma LOL che figata)

http://explain.depesz.com/
Copy'n'paste your query plan, it will highligth all the 'bad steps'.

Dont know how does this works withour knowing the database structure, data-types and indexes, but.. its not bad

Loading mentions Retweet
Filed under  //   Database   Postgresql  
Posted June 22, 2009
// 0 Comments

How do I perform regular expression searches and case-insensitive regular expression searches? How do I use an index for case-insensitive searches?

The ~ operator does regular expression matching, and ~* does case-insensitive regular expression matching. The case-insensitive variant of LIKE is called ILIKE.

Case-insensitive equality comparisons are normally expressed as:

SELECT *
FROM tab
WHERE lower(col) = 'abc';

This will not use a standard index on "col". However, if you create an expression index on "lower(col)", it will be used:

CREATE INDEX tabindex ON tab (lower(col));

If the above index is created as UNIQUE, then the column can store upper and lowercase characters, but it can not contain identical values that differ only in case. To force a particular case to be stored in the column, use a CHECK constraint or a trigger.

Loading mentions Retweet
Posted June 22, 2009
// 0 Comments

Campagna di Sensibilizzazione per L'aggiornamento del Browser

Loading mentions Retweet
Posted June 19, 2009
// 0 Comments

Making work the jQuery AutoComplete plugin with a json output format even in Internet Explorer

Original code: http://jquery.bassistance.de/autocomplete/demo/json.html

But this wont work in IE.

After reading http://groups.google.it/group/jquery-en, thanks to this thread and the zandog74 solution, that's what i got:

$('input#contact-list').autocomplete('test-db.php', {
        multiple: false,
        dataType: "json",
        width: 400,
        scrollHeight: 300,
        max: 25,
        parse: function(data){ //this is very important, all my problems was 'hot to format the damned json'
            var parsed = [];
            for (var i=0; i < data.length; i++){
                var row = data[i];
                parsed.push({
                    data: row,
                    value: row["azienda"],
                    result: "Attendere..."
                });
            }
            return parsed;
        },

        formatItem: function(item) {
            return item.azienda + '<br />' + item.nome + ' ' + item.cognome + '<br />' + item.email;
        }
    }).result(function(e, item) {
        //this will be triggered when the selection has made
        //alert(item.id_azienda + '-' + item.id_user);
        $.ajax({
            type: "POST",
            cache: false,
            data: "idAzienda=" + item.id_azienda + "&idReferente=" + item.id_user,
            url: "test-db-02.php",
            success: function(message){
                //whatever you need to do when the user make the selection
            }
        });
    });
    //nevermind that
    $("div#deselect-contact").click(function(){
        $("div#selected-contact").html('');
        $("input#contact-list").val('');
        $("input[rel='ship']").attr("readonly", false).css("background-color", "#FFFFFF").val('');
        $("input[rel='company']").attr("readonly", false).css("background-color", "#FFFFFF").val('');
        $("div#contact-list-container").css("display", "inline").css("visibility", "visible");
        $("div#contact-list-selected").css("display", "none").css("visibility", "hidden");
    });

Full cross-browser.
Anyway, Internet Explorer MUST DIE.

Loading mentions Retweet
Posted June 19, 2009
// 0 Comments