Языки кроме SQL в пост-ГРЭС
Помимо превосходных ответов выше, я бы написал функцию C, которая не использует никаких библиотек и имеет некоторые защиты от плохих строк.
uint8_t* datahex(char* string) {
if(string == NULL)
return NULL;
size_t slength = strlen(string);
if((slength % 2) != 0) // must be even
return NULL;
size_t dlength = slength / 2;
uint8_t* data = malloc(dlength);
memset(data, 0, dlength);
size_t index = 0;
while (index < slength) {
char c = string[index];
int value = 0;
if(c >= '0' && c <= '9')
value = (c - '0');
else if (c >= 'A' && c <= 'F')
value = (10 + (c - 'A'));
else if (c >= 'a' && c <= 'f')
value = (10 + (c - 'a'));
else {
free(data);
return NULL;
}
data[(index/2)] += value << (((index + 1) % 2) * 4);
index++;
}
return data;
}
Объяснение:
а. index / 2 | Разделение между целыми числами округляет значение, поэтому 0/2 = 0, 1/2 = 0, 2/2 = 1, 3/2 = 0 и т. Д. Итак, для каждых 2 строковых символов мы добавляем значение в 1 байт данных .
b. (индекс + 1)% 2 | Мы хотим, чтобы нечетные числа приводили к 1 и даже к 0, поскольку первая цифра шестнадцатеричной строки является самой значительной и ее необходимо умножить на 16. Таким образом, для индекса 0 => 0 + 1% 2 = 1, индекс 1 => 1 + 1% 2 = 0 и т. Д.
c. & Л; & л; 4 | Сдвиг на 4 умножается на 16. пример: b00000001 & lt; 4 = b00010000
6 ответов
"не то, что [текстовое управление] больше из чего-то, что должно быть запрограммировано в приложение?"
Обычно, да. Общепринятое "трехуровневое" проектирование приложений для баз данных говорит, что Ваша логика должна быть на среднем уровне между клиентом и базой данных. Однако иногда Вам нужна некоторая логика в триггере или потребности индексировать на функции, требуя что некоторый код быть помещенными в базу данных. В этом случае все обычное, "который язык я должен использовать?" вопросы подходят.
Если Вам только нужны немного логики, большинство - портативный язык должен, вероятно, использоваться (pl/pgSQL). Если необходимо сделать некоторое серьезное программирование, хотя, Вы могли бы быть более обеспеченным использованием более выразительного языка (возможно, мн/рубиновый). Это всегда будет личным выбором.
"есть ли какая-либо допустимая причина использовать недоверяемый язык?"
Как выше, да. Снова, помещение доступа файла прямого доступа (например), на Ваш средний уровень является лучшим, если это возможно, но если необходимо исчерпать вещи на основе триггеров (которому, возможно, понадобился бы доступ к данным, не доступным непосредственно среднему уровню), затем Вам нужны недоверяемые языки. Это не идеально, и должно обычно избегаться. И определенно необходимо охранять доступ к нему.
@Mike: этот вид взглядов раздражает меня. Я слышал к много раз, "это должно быть бесконечно портативно", но когда вопрос задают: Вы на самом деле предвидите, что будет какое-либо портирование? ответ: нет.
Придерживание наименьшего общего знаменателя может действительно повредить производительность, как может введение уровней абстракции (ORM's, PHP PDO, и т.д.). Мое мнение:
- Оцените реалистично, если существует потребность поддерживать несколько RDBMS. Например, если Вы пишете веб-приложение с открытым исходным кодом, возможности состоят в том, что необходимо поддерживать MySQL и PostgreSQL, по крайней мере (если не MSSQL и Oracle)
- После оценки максимально используйте платформу, которую Вы выбрали
И BTW: Вы смешиваетесь реляционный с базами данных неотношения (CouchDB не является RDBMS, сопоставимый с Oracle, например), далее иллюстрируя точку, что воспринятая потребность в мобильности много раз значительно завышается.
Недоверяемые версии процедурных языков позволяют Вам получать доступ к вводу-выводу в системе. Это может пригодиться, если Вам нужен триггер, или что-то посылает электронное письмо или подключение к серверу сокета для отправки раскрывающегося уведомления. Существуют тонны использования для этого типа вещи, и из-за postgresql уровней изоляции Вы, банки безопасно делают вещи как это. Можно поместить контрольные точки в функцию поэтому, если транзакция приводит электронную почту к сбою или независимо от того, что не выйдет. Хорошая вещь о выполнении этого является этим, удаляет логику от клиента и помещает его на сервер.
Я думаю, что большинство дополнительных языков предлагается так, чтобы, если Вы разрабатываете на том языке регулярно, можно было чувствовать себя комфортно, пишущий функции дб, триггеры, и т.д. Полноценность этих функций состоит в том, чтобы обеспечить управление данными максимально близко к данным.
С моей точки зрения я предполагаю, что ответ, 'это зависит'.
Существует аргумент, что управление данными принадлежит слоя базы данных, так, чтобы бизнес-логика не должна была чрезмерно касаться тем, как управление происходит, это просто знает, что имеет.
Другое очень серьезное основание обработать данные на слое дб состоит в том, если объем данных, уплотняемых средства, что сетевая пропускная способность станет проблемой. Я когда-то должен был категоризировать очень большие объемы данных. Обработка этого на прикладном уровне была severly, ограниченным, к тому времени, когда требуется для передачи всех данных по сети для обработки.
Я затем записал binning алгоритм в PL/pgSQL, и он работал намного быстрее.
Относительно недоверяемых языков я слышал подкаст от Josh Berkus (защитник пост-ГРЭС), кто обсудил приложение postgresql, который ввел данные из MySQL как часть его обработки, так, чтобы сама коммуникация была обработана сервером пост-ГРЭС. Я не помню полное изложение, я думаю, что это было на подкасте FLOSS Weekly, который является вполне интересным обсуждением истории PostGRESQL и некоторые проблемы, в которые это помещается.
В эти дни любая "уникальная" или "прохладная" функция в DBMS раздражает меня невероятно. Я вспыхиваю в сыпи и должен остановить работу, пока зуд не уходит.
Я просто очень не хочу быть привязанным на платформу излишне. Предположим, что Вы создаете большой блок своей системы во внутреннем МН / Perl, внутренний база данных. Или в C# в SQL Server, или МН / SQL в Oracle, существует много examples*.
Теперь Вы внезапно обнаруживаете, что Ваша выбранная платформа не масштабируется. Или не достаточно быстро. Или что-то. Хуже, существует новый ребенок на блоке базы данных (что-то как MonetDB, CouchDB, Кэш, заявляют, но намного более прохладный), который решил бы все Ваши проблемы (даже если Ваша единственная проблема, как моя, имеет некрутую databse платформу). И Вы не можете переключиться на него, не повторно кодируя половину Вашего приложения.
(*Admittedly, заплаченные - для продуктов в некоторой степени стремятся привязать Вас, убеждая Вас использовать их уникальные функции, который не является обвинением, которое может непосредственно быть выдвинуто против свободных поставщиков, но эффект является тем же).
Таким образом, это - напыщенная речь на первой части вопроса. Сердечный, все же.
там какая-либо допустимая причина состоит в том, чтобы использовать недоверяемый язык? Это походит на создание его так, чтобы любой пользователь мог выполниться, любая операция была бы плохой идеей
Мое совершенство, да это делает! Своего рода "нападение инжекции Perl"? Почти стоящий выполнения его только для наблюдения, что происходит я думал бы.
По философским причинам, обрисованным в общих чертах выше, я думаю, что передам проблему PL/LOLCODE. Хотя я был несколько поражен обнаружить, что это была ссылка на что-то существующее.