Преобразуване на типове полета чрез COMPUTED BY
Както можете да видите, синтаксисът предлага да се посочи или тип колона (тип данни), или изчислен израз (изчислен от). Индикацията „или/или“ е символът . Обикновено типът COMPUTED BY на поле е същият като типа вход, на който се основава. Въпреки това е възможно изрично да се дефинира конкретен тип колона, дори ако не съвпада с оригиналния.
Можете да направите следния експеримент - да създадете таблица с дадената структура: (дефиницията на PRIMARY KEY може да бъде пропусната, защото е въведена тук само за удобство при работа с такава таблица от Database Explorer, тъй като BDE не позволява актуализиране на таблици, които нямат първичен ключ)
Сега опитайте да въведете записи в тази таблица със следната стойност на T_DATA: 1.88, 3.2, 3.51. Ще видите, че полето тип FLOAT не съхранява точно стойностите, които сте въвели на диска. Полето C_INT съдържа закръглената стойност T_DATA. Полето C_NUM ще съдържа или точната стойност на T_DATA, или закръглена стойност, в зависимост от стойността на параметъра за псевдоним BDE ENABLE BCD = TRUE/FALSE. Но C_CHAR ще съдържа по-точна стойност на реалното число C_DATA.
От това следват няколко извода:
- прецизността на реалните числа е ограничена и число, съхранено като реално число, никога не може да бъде сравнено за равенство (това е добре известно правило)
- прецизността на полетата FLOAT е много ниска (еквивалентна на Delphic single), така че е по-добре вместо това да използвате DOUBLE PRECISION
- не всички типове се преобразуват от един в друг - NUMERIC(15, 2) поле като INTEGER COMPUTED BY. ще съдържа 0.
- при обработка на реални числа (закръгляване, сумиране, сравнение, събиране/изваждане и умножение/деление) трябва да се вземе предвид грешката. Също известно счетоводно правило - при умножение и деление първо се извършва умножението.
- реалните типове не трябва да се използват като първични ключове на таблици - поради грешка или особеност при обработката на реални числа от клиентски и сървърни процесори, уж едно и също число може да се окаже различно и записът от първичния ключ може да бъде "загубен". Например, заявка select * from testcomp where t_data = 1.88 може да върне празен резултат.