Каково Большое-O для выбора SQL?

Для всех типов я приготовил Объектную опытную функцию. Это может быть полезно для Вас

Object.prototype.typof = function(chkType){
      var inp        = String(this.constructor),
          customObj  = (inp.split(/\({1}/))[0].replace(/^\n/,'').substr(9),
          regularObj = Object.prototype.toString.apply(this),
          thisType   = regularObj.toLowerCase()
                        .match(new RegExp(customObj.toLowerCase()))
                       ? regularObj : '[object '+customObj+']';
     return chkType
            ? thisType.toLowerCase().match(chkType.toLowerCase()) 
               ? true : false
            : thisType;
}

Теперь, можно проверить любой тип как это:

var myDate     = new Date().toString(),
    myRealDate = new Date();
if (myRealDate.typof('Date')) { /* do things */ }
alert( myDate.typof() ); //=> String

[ Редактирование идет 2013 ] на основе прогрессирующего понимания, это - лучший метод:

Object.prototype.is = function() {
        var test = arguments.length ? [].slice.call(arguments) : null
           ,self = this.constructor;
        return test ? !!(test.filter(function(a){return a === self}).length)
               : (this.constructor.name ||
                  (String(self).match ( /^function\s*([^\s(]+)/im)
                    || [0,'ANONYMOUS_CONSTRUCTOR']) [1] );
}
// usage
var Some = function(){ /* ... */}
   ,Other = function(){ /* ... */}
   ,some = new Some;
2..is(String,Function,RegExp);        //=> false
2..is(String,Function,Number,RegExp); //=> true
'hello'.is(String);                   //=> true
'hello'.is();                         //-> String
/[a-z]/i.is();                        //-> RegExp
some.is();                            //=> 'ANONYMOUS_CONSTRUCTOR'
some.is(Other);                       //=> false
some.is(Some);                        //=> true
// note: you can't use this for NaN (NaN === Number)
(+'ab2').is(Number);                 //=> true
22
задан Graviton 28 August 2009 в 15:07
поделиться

3 ответа

Поскольку вы не контролируете выбранный алгоритм, нет возможности узнать напрямую. Однако без индексов SELECT должен быть O (n) (сканирование таблицы должно проверять каждую запись, что означает, что она будет масштабироваться с размером таблицы).

С индексом SELECT, вероятно, будет O (log (n) ) (хотя это будет зависеть от алгоритма, используемого для индексации, и свойств самих данных, если это верно для любой реальной таблицы). Чтобы определить свои результаты для любой таблицы или запроса, вы должны прибегнуть к профилированию реальных данных, чтобы быть уверенным.

INSERT без индексов должен выполняться очень быстро (близко к O (1)), в то время как UPDATE необходимо сначала найти записи и так будет медленнее (немного), чем SELECT, который доставит вас туда.

INSERT с индексами, вероятно, снова будет приближаться к O (log (n ^ 2)), когда дерево индексов необходимо перебалансировать, ближе к O (log (n)) в противном случае. Такое же замедление произойдет с UPDATE, если оно затронет индексированные строки, помимо затрат на SELECT.

Все ставки отключены, когда вы говорите о JOIN в миксе: вам придется профилировать и использовать инструменты оценки запросов к базам данных чтобы прочитать об этом. Также обратите внимание, что если этот запрос критичен к производительности, вам следует время от времени перепрофилировать , поскольку алгоритмы, используемые вашим оптимизатором запросов, будут меняться по мере изменения загрузки данных.

Еще одна вещь, о которой следует помнить ... big-O не сообщает вам о фиксированных затратах для каждой транзакции. Для небольших таблиц они, вероятно, выше, чем фактические затраты на работу. В качестве примера: затраты на настройку, удаление и обмен данными кросс-сетевого запроса для одной строки наверняка будут больше, чем поиск индексированной записи в небольшой таблице.

43
ответ дан 29 November 2019 в 04:33
поделиться

Я думаю, что настоящий ответ может быть определен только в каждом конкретном случае (механизм базы данных, дизайн таблиц, индексы и т. Д.).

Однако, если вы используете MS SQL Server пользователь, вы можете ознакомиться с предполагаемым планом выполнения в Query Analyzer (2000) или Management Studio (2005+). Это дает вам много информации, которую вы можете использовать для анализа.

1
ответ дан 29 November 2019 в 04:33
поделиться

Все зависит от того, насколько (хорошо) вы пишете свой SQL и насколько хорошо ваша база данных спроектирована для выполняемой вами операции. Попробуйте использовать функцию объяснения плана, чтобы увидеть, как все будет выполняться db. Файл. Вы можете вычислить большой O

0
ответ дан 29 November 2019 в 04:33
поделиться
Другие вопросы по тегам:

Похожие вопросы: