Мне нужно выполнить миграцию данных из базы данных, и я не слишком хорошо знаком с базами данных, поэтому мне хотелось бы получить некоторые пояснения. У меня есть документация, которая может применяться как к базе данных Oracle, так и к базе данных SQL, и имеет столбец, определяемый как NUMBER (10,5). Я хотел бы знать, что это значит. Я думаю, это означает, что число имеет 10 цифр с 5 после десятичной точки, но я хотел бы уточнить. Также будет ли это отличаться для SQL или Oracle?Определения полей базы данных
ответ
Первое число - точность второе число - шкала. Эквивалент в SQL Server может быть в виде десятичного/Числовой, и вы могли бы определить его следующим образом:
DECLARE @MyDec decimal(18,2)
18 является максимальным общим количеством десятичных цифр, которые могут быть сохранены (то есть общее количество цифр, например, 123.45 точность здесь равна 5, а масштаб равен 2). 2 - масштаб, и он указывает максимальное количество цифр, хранящихся справа от десятичной точки.
См this article
Просто помните больше точности, тем больше размер в байтах для хранения. Поэтому держите его как можно скорее.
р (точность)
Определяет максимальное общее количество десятичных цифр, которые могут быть сохранены, как слева и справа от десятичной запятой. Точность должна быть значением от 1 до максимальной точности . Максимальная точность 38. Точность по умолчанию 18.
с (шкала)
Задает максимальное число десятичных цифр, которые могут быть сохранены, чтобы справа от десятичной запятой. Масштаб должен быть значением от 0 до p. Масштаб может быть указан только в том случае, если задана точность . Шкала по умолчанию равна 0; поэтому 0 < = s < = p. Максимальные размеры хранилища варьируются в зависимости от точности.
Наконец, стоит упомянуть, что в оракуле вы можете определить масштаб больше точности, например, число (3, 10) действует в оракуле. SQL Server, с другой стороны, требует точности> = шкалы. Поэтому, если вы определили Number (3,10) в oracle, он будет отображаться в sql как Number (10,10).
В Oracle столбец, определяемый как NUMBER (4,5), требует нуля для первой цифры после десятичной точки и округляет все значения после пятой цифры после десятичной точки.
NUMBER(p,s)
где: р является точность, или общее количество цифр. Oracle гарантирует переносимость номеров с точностью от 1 до 38. s - это масштаб или число цифр справа от десятичной точки.Шкала может находиться в диапазоне от -84 до 127.
Вот некоторые примеры:
Фактические данные, хранящиеся в .000127
NUMBER(4,5)
.00013
становится
Фактические данные, хранящиеся в 7456123.89
NUMBER(7,-2)
становится 7456100
Отредактировано
JONH упоминает что-то примечательное:
Oracle позволяет масштаб> точность, так SQL сопоставляются, что так что если s> р, то р становится s. Это NUMBER (3, 4) в oracle становится NUMERIC (4,4) в SQL.
Кроме того, SQL не поддерживает масштаб, который будет больше точности. Оп попросил обе поддержки. Oracle позволяет масштабировать> точность, поэтому SQL будет отображать это так, что если s> p, то p становится s. Это NUMBER (3, 4) в oracle становится NUMERIC (4,4) в SQL. – JonH
Определение столбца в Oracle как NUMBER (10,5) означает, что значение столбца может иметь десятичное число до пяти точек точности и десять цифр общей длины. Если вы введете значение в столбец, который не имеет определенных десятичных знаков, максимальный столбец будет поддерживать 10 цифр. Например, эти значения будут поддерживаться столбцом, определенным как NUMBER (10,5):
1234567890
12345.67890
Это сделало валидацию болью.
MySQL и SQL Server не поддерживают тип данных NUMBER - для поддержки десятичных знаков вы используете DECIMAL (или FLOAT?). Я не смотрел PostgreSQL, но я бы подумал, что он похож на Oracle.
DECIMAL/NUMERIC являются эквивалентами и поддерживаются SQL Server. Поплавки в sql-сервере сопоставляются с реальными в oracle. – JonH
И никогда не используйте float, если вам нужно выполнить вычисления! – HLGEM
@JonH: 'NUMERIC'! =' NUMBER'; функциональность аналогична, но ключевое слово отсутствует. Похоже на расщепление волос, но это будет означать, что вы не можете переносить скрипты из одного в другое без вмешательства. –
- 1. Дублирование полей базы данных
- 2. Переименование полей базы данных
- 3. Django дубликатом определения модели/полей
- 4. отображение полей базы данных mysql
- 5. Именование полей таблицы базы данных
- 6. сравнения двух полей данных из базы данных
- 7. Как получить значение полей базы данных из базы данных sqlite?
- 8. Преобразование файлов определения базы данных в SQL
- 9. Определения таблицы из указанной базы данных
- 10. два различных определения схемы базы данных
- 11. Соединение JDBC без определения базы данных
- 12. Нужно комментировать эксперт по поводу определения базы данных или базы данных базы данных
- 13. Использование объекта в качестве определения таблицы базы данных?
- 14. Ограничение значений полей базы данных на основе комбинаций других полей
- 15. Возврат только обновленных полей из базы данных
- 16. Где вы помещаете имена полей базы данных?
- 17. Дизайн базы данных переменной величины полей
- 18. MySQL базы данных - оптимизация же несколько полей
- 19. Обновление базы данных из нескольких текстовых полей
- 20. Как получить имена полей таблицы базы данных?
- 21. Заполнение текстовых полей из базы данных SQL
- 22. Прохождение полей базы данных через функции
- 23. Экспорт полей базы данных Mongo в txt
- 24. Проблема с заполнением всех полей базы данных
- 25. копии таблиц/полей базы данных postgreSQL
- 26. полей базы данных используя первый, 1,2, ..., последний
- 27. Записи базы данных Ajax для нескольких полей
- 28. Динамическое отображение полей из таблицы базы данных
- 29. Размер по умолчанию для полей базы данных
- 30. Использование конкатенированных переменных для полей базы данных
Если вы выполняете миграцию данных, и вы даже не знаете базовые типы данных, которые вы находитесь над головой. Это НЕ задача, которую новичок должен даже попробовать. Вам нужны передовые навыки, и у вас даже нет базовых. – HLGEM
Технически я этого не делаю. Но один из моих коллег был отладки и проблема в миграции данных, просят мое мнение, и мы оба были не уверены, правильно ли мы интерпретировали документацию или нет. – user381261