|
|
|
всегда ли определять Number?
|
|||
|---|---|---|---|
|
#18+
всегда ли определять Number? то есть всегда ли нужно писать, допустим, Number (20,10)? или не заморачиваться с этим? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.06.2017, 10:41 |
|
||
|
всегда ли определять Number?
|
|||
|---|---|---|---|
|
#18+
Решать вам, Но процитирую дядю Тома :) Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1619552483055 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.06.2017, 10:52 |
|
||
|
всегда ли определять Number?
|
|||
|---|---|---|---|
|
#18+
На просто number'е сталкивался, что когда прикладная приложения float в БД пишет... там иногда такие "странности" получаются. Не все NaN (not a number) в прикладных языках совпадают с NaN в Oracle, и не все драйверы в прикладных языках корректно это обрабатывают. Потом очень приятно черти какие записи с NaN'ами, на которых JDBC просто падает, в 100-200 Гб базе отыскивать. Было бы указание размерности/точности у поля, таких глюков бы не было. IMHO ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.06.2017, 11:01 |
|
||
|
всегда ли определять Number?
|
|||
|---|---|---|---|
|
#18+
p.s. не JDBC падало, но в Java оно приходило не как NaN, а как черти какое число.... после чего уже падал COPY в PostgreSQL, куда программа это число пыталась вставить.... не помню точно, но как-то очень не приятно было... На всю базу 200 Gb, 4-5 записей таких было. С учетом, что в базе Primary Key были как number'ы из float )))... очень приятно... Первый раз видел БД, где в качестве Primary Key NUMBER, в который пишут float. Как и с каким шагом они его автоинкрементели, х.з., не помню, даже не интересовался. Просто выругался матом и принял как данность. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.06.2017, 11:09 |
|
||
|
всегда ли определять Number?
|
|||
|---|---|---|---|
|
#18+
pgiw99oeoто есть всегда ли нужно писать, допустим, Number (20,10)?Где? Может ли INT-параметр иметь дробную часть? - Увы... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.06.2017, 12:52 |
|
||
|
всегда ли определять Number?
|
|||
|---|---|---|---|
|
#18+
просто я немножко пытался вникнуть, и вроде тип намбер ведет себя как варчар2, т.е. если число короткое, допустим из трех цифр, то пишутся только эти 3 цифры, и память отводится только под эти 3 цифры (ну, может там еще разделитель полей, не суть) поэтому и заинтересовался стоит ли вообще чего-то экономить, не вижу особой разницы между NUMBER и NUMBER(20,10) зы. может я чего-то неправильно понял ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.06.2017, 16:57 |
|
||
|
всегда ли определять Number?
|
|||
|---|---|---|---|
|
#18+
pgiw99oeoесли число короткое, допустим из трех цифр, то пишутся только эти 3 цифры, и память отводится только под эти 3 цифры (ну, может там еще разделитель полей, не суть)Дьявол - в деталях. RTFM Numeric Data Types (FAQ) pgiw99oeoстоит ли вообще чего-то экономитьВ нынешнее время этот критерий становится всё менее значимым. pgiw99oeoне вижу особой разницы между NUMBER и NUMBER(20,10)Тип данных должен соответствовать бизнес-понятию. Например, "Количество": как "штуки" должно допускать только целочисленные значения (2,5 книги - бред); как "объём" должно допускать и дробные значения (заказал 30л, а влезло 27,473л). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2017, 08:07 |
|
||
|
всегда ли определять Number?
|
|||
|---|---|---|---|
|
#18+
ElicТип данных должен соответствовать бизнес-понятию. Например, "Количество": как "штуки" должно допускать только целочисленные значения (2,5 книги - бред); как "объём" должно допускать и дробные значения (заказал 30л, а влезло 27,473л). Неудачный пример. То есть, при складском учете , например, на каждый тип "Количества" свой тип данных закладывать закладывать что ли? ИМХО, бред. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2017, 13:48 |
|
||
|
всегда ли определять Number?
|
|||
|---|---|---|---|
|
#18+
efendi, А check- или ref- constraint-ы прописывать тоже бред? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2017, 18:09 |
|
||
|
всегда ли определять Number?
|
|||
|---|---|---|---|
|
#18+
coborhcefendi, А check- или ref- constraint-ы прописывать тоже бред? А какое отношение имеет этот вопрос к обсуждаемой теме? Как наличие check- или ref- constraint-ов повлияет на размерность поля Number, заданного при создании таблицы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2017, 19:11 |
|
||
|
всегда ли определять Number?
|
|||
|---|---|---|---|
|
#18+
efendi, "Чукча - не читатель"? Выше цитата была: авторThe advantage is a) you have 5 digits only, never more b) you have no decimals, it is an integer type consider it a constraint -- like a primary key, NOT NULL, check, whatever. If your data is such that the number should never be more then 5 digits, the only correct way to implement it would be as a number(5) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2017, 20:20 |
|
||
|
всегда ли определять Number?
|
|||
|---|---|---|---|
|
#18+
coborhcefendi, "Чукча - не читатель"? Выше цитата была: авторThe advantage is a) you have 5 digits only, never more b) you have no decimals, it is an integer type consider it a constraint -- like a primary key, NOT NULL, check, whatever. If your data is such that the number should never be more then 5 digits, the only correct way to implement it would be as a number(5) Не надо путать кислое с пресным. Указание размерности ограничивает только диапазон хранимых значений, например, не больше 5 знаков. Если же на этот диапазон надо наложить дополнительное правило, например, только положительные значения, то тогда на поле вешают check. Или forerign key, если в поле хранится ссылка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2017, 21:52 |
|
||
|
всегда ли определять Number?
|
|||
|---|---|---|---|
|
#18+
efendiНе надо путать кислое с преснымЭто ты ещё зелен. Точность и длина с масштабом - это своего рода ограничения целостности. хранение varchar2 varchar2(255) и varchar2(4000) Необходимо ли указывать на размерность Number при создании полей одна длина varchar2 на все поля ? Вопрос о хранении типа NUMBER ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2017, 22:53 |
|
||
|
всегда ли определять Number?
|
|||
|---|---|---|---|
|
#18+
efendiНе надо путать кислое с пресным. Указание размерности ограничивает только диапазон хранимых значений, например, не больше 5 знаков. Если же на этот диапазон надо наложить дополнительное правило, например, только положительные значения, то тогда на поле вешают check. Или forerign key, если в поле хранится ссылка.Это тебе не надо выдумывать виртуальное разделение integrity constraints. Указание точности типа данных также как check или not null constraint это дополнительное ограничение целостности на данные. При этом, при указании типа надо указывать ограничение настолько жестко насколько это возможно и необходимо. Например, если необходимо указать, что строка должна быть от 1 до 5 символов это можно сделать так Код: plsql 1. 2. 3. 4. 5. а особо творческие личности могут сделать так Код: plsql 1. 2. 3. 4. 5. 6. 7. С точки зрения логики можно считать идентичным, но если можно обойтись без check - лучше обойтись. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2017, 00:49 |
|
||
|
всегда ли определять Number?
|
|||
|---|---|---|---|
|
#18+
ElicТочность и длина с масштабом - это своего рода ограничения целостности. К сожалению точность - не ограничение. С указанной точностью происходит округление, сиречь искажение сохраняемых значений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2017, 09:43 |
|
||
|
всегда ли определять Number?
|
|||
|---|---|---|---|
|
#18+
efendiТо есть, при складском учете , например, на каждый тип "Количества" свой тип данных закладывать закладывать что ли? ИМХО, бред. Не бред а профессиональный подход к проектированию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2017, 09:46 |
|
||
|
всегда ли определять Number?
|
|||
|---|---|---|---|
|
#18+
3.1415К сожалению точность - не ограничение. С указанной точностью происходит округление, сиречь искажение сохраняемых значений. Меня, к слову, весьма люто от этого бомбит. Вплоть до того, что я предложил бы в ряде случаев ограничивать точность именно чеками. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2017, 09:56 |
|
||
|
всегда ли определять Number?
|
|||
|---|---|---|---|
|
#18+
3.1415ElicТочность и длина с масштабом - это своего рода ограничения целостности.К сожалению точность - не ограничение. С указанной точностью происходит округление, сиречь искажение сохраняемых значений.Я малость не так написал. Точность с масштабом и длина. Т.е. в паре. В number(38, 38) ты не влезешь как ни округляй. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2017, 09:57 |
|
||
|
всегда ли определять Number?
|
|||
|---|---|---|---|
|
#18+
XMLerefendiТо есть, при складском учете , например, на каждый тип "Количества" свой тип данных закладывать закладывать что ли? ИМХО, бред. Не бред а профессиональный подход к проектированию. Ну, давай, прояви профессиональный подход к проектированию, и покажи на примере Elic-a, сколько должно быть полей для учета количества различных видов материалов на складе и какой они должны быть размерности? И как скажем будет выглядеть запрос для подсчета общей стоимости всех материалов на складе? ElicТип данных должен соответствовать бизнес-понятию. Например, "Количество": как "штуки" должно допускать только целочисленные значения (2,5 книги - бред); как "объём" должно допускать и дробные значения (заказал 30л, а влезло 27,473л). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2017, 13:08 |
|
||
|
всегда ли определять Number?
|
|||
|---|---|---|---|
|
#18+
ElicefendiНе надо путать кислое с преснымЭто ты ещё зелен. Точность и длина с масштабом - это своего рода ограничения целостности. efendi Указание размерности ограничивает только диапазон хранимых значений, например, не больше 5 знаков. И что я сказал не так? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2017, 13:11 |
|
||
|
всегда ли определять Number?
|
|||
|---|---|---|---|
|
#18+
efendiсколько должно быть полей для учета количества различных видов материалов на складе и какой они должны быть размерности?Хоть это и оффтоп, но на складах хранят исчислимые материалы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2017, 13:13 |
|
||
|
всегда ли определять Number?
|
|||
|---|---|---|---|
|
#18+
efendiсколько должно быть полей для учета количества различных видов материалов на складе и какой они должны быть размерности? Два? number(9) для количества и number(<=9) для ссылки на единицу измерения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2017, 13:28 |
|
||
|
всегда ли определять Number?
|
|||
|---|---|---|---|
|
#18+
efendi, імхо, склад складу рознь, напр металлобаза и аптечный зы imho, для склада явно не int ..... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2017, 13:35 |
|
||
|
всегда ли определять Number?
|
|||
|---|---|---|---|
|
#18+
stax..зы imho, для склада явно не int ..... stax не скажи, может там все в штуках меряется ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2017, 13:50 |
|
||
|
всегда ли определять Number?
|
|||
|---|---|---|---|
|
#18+
123ййstax..зы imho, для склада явно не int ..... stax не скажи, может там все в штуках меряется трудно представить, всегда найдутся умельцы выдать пол рулона, чверть бутылки, 5таблеток из пачки и тд .... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2017, 13:54 |
|
||
|
|

start [/forum/search_topic.php?author=JimKlimov&author_mode=last_posts&do_search=1]: |
0ms |
get settings: |
11ms |
get forum list: |
18ms |
get settings: |
9ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
59ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
69ms |
get tp. blocked users: |
2ms |
| others: | 424ms |
| total: | 629ms |

| 0 / 0 |
