|
|
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
1. Я не считаю безразмерный varchar хорошей фичей, но не возражаю против таковой 2. Длинная арифметика нужна (с точностью больше 18), но это не значит, что она будет безразмерной 3. Как оно там сортируется это отдельный вопрос и вообще мало зависит от того есть безразмерные типы или нету ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.08.2014, 23:11 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovNickDeeещё увидел Повторяю вопрос медленно: кодить всю эту хрень ты будешь? Я ж тебе ответил вопросом на вопрос. Какие проблемы с новыми разработчиками? Они приходят но отбриваются? Они не приходят? Почему разработчиков всего пять? Спонсоры дают мало денег? Или ты мне предлагаешь пройти этот путь и на себе понять что там не так, кто виноват и что делать с упырями? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.08.2014, 23:23 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
Симонов Денис2. Длинная арифметика нужна (с точностью больше 18), но это не значит, что она будет безразмернойЕсли бы был "выход в яву" из хранимок ФБ, то все вопросы по длинной арифметике ушли бы в небытиё. В том числе и про размеры. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2014, 00:00 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
NickDeeИли ты мне предлагаешь пройти этот путь и на себе понять что там не так, кто виноват и что делать Ага, именно так. Тогда мы и увидим что эти твои "увиденные косяки" могут принести хорошего, а что - плохого. А Таблоид позаботится чтобы продемонстрировать с цифрами в руках насколько твои "безразмерные типы" будут тормозить. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2014, 00:45 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovА Таблоид позаботится чтобы продемонстрировать с цифрами в руках насколько твои "безразмерные типы" будут тормозить.я в упор не понимаю, для чего нужна сортировка сверхдлинных строк. Кто будет глаза ломать об них, да еще учитывая, что на мониторах они всё равно не отобразятся даже в 1% своей длины ? Сами по себе длинные строки (большие числа ?) - может, и нужны где-то. В криптиграфии с открытым ключём, например. Но это не СУБДшная задача таки. Совсем. ЗЫ. И даже если представить, что сортировка таких строк позарез нужна, что мешает сделать таблицу со 100 полями varchar(100), в которых эти строки будут в "раздробленном виде", и выполнять из неё 100 раз заливку в GTT1 с order by F_01, затем из GTT1 в GTT2 с order by F_02, затем обратно - из GTT2 в GTT1 с order by F_03 и т.д. до 100-го поля ? Может, и выглядит как бред, но эти 100 заливок-сортировок если и будут во что-то упираться, то точно не в размер памяти. В эффективность нынешнего доступа к GTT "почти как" к FIXED-таблицам - да, будут. Но ежели ФБ-светила когда-нибудь подправят GTT-консерваторию, или вообще сделают таблицы в памяти (a'la mon$), то проблема вообще исчезнет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2014, 01:11 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
ТаблоидDimitry SibiryakovА Таблоид позаботится чтобы продемонстрировать с цифрами в руках насколько твои "безразмерные типы" будут тормозить.я в упор не понимаю, для чего нужна сортировка сверхдлинных строк. Кто будет глаза ломать об них, да еще учитывая, что на мониторах они всё равно не отобразятся даже в 1% своей длины ? Так без разницы по чему сортировать, хоть по ID, всё-равно запись в памяти хранится по объявленной в метаданных длине. Попробуй написать функцию, которая аппит варчар: Код: sql 1. 2. 3. 4. а дальше попробуй иcпользовать её: Код: sql 1. 2. Размер одной записи выборки около 32 килобайт. Чтобы посортировать миллион таких в памяти, нужно около 32ГБ памяти. Как решить проблему? Да элементарно, нужно объявить функцию: Код: sql 1. 2. 3. 4. И писать Код: sql 1. А как же быть если нужно такое делать и для других таблиц, где размер варчара например 100? Да элементарно, нужно объявить функцию: Код: sql 1. 2. 3. 4. И писать Код: sql 1. А как же быть если варчаров много разных? Да элементарно, нужно объявить много функций, по количеству варчаров, по шаблону: Код: sql 1. 2. 3. 4. И писать Код: sql 1. *ботня, не правда ли? :) Это то, на что обрекает пользователей текущая реализация VARCHAR(N). Кстати в Firebird есть системная функция Upper, которая удивительным образом возвращает не varchar(32000), а varchar(длина параметра). А ка же быть не системным функциям? Кстати, а если бы была системная функция Str2Hex, то варчар какой ширины она бы возвращала? длина_параметра * 2? А обратная бы делила на два? :) А как написать такую функцию используя механизм UDR? Входной параметр блоб и выходной блоб? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2014, 02:31 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
NickDee, гнусный ты провокатор. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2014, 03:21 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
kdvNickDee, гнусный ты провокатор. Да просто с такими удобствами вы весь userbase растеряете. Попробуй в Delphi закодить бизнес-логику на процедурах с параметрами типа string[n]. Понравится тебе? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2014, 05:38 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
NickDee, ты вообще читаешь чужие сообщения. Сортировка широких выборок может делаться по другому. Читай и пробуй 13198664 . P.S. Что ещё кто-нибудь пользуется UDFкой переводящей строку в верхний регистр? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2014, 10:15 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
NickDeeДа просто с такими удобствами вы весь userbase растеряете. Попробуй в Delphi закодить бизнес-логику на процедурах с параметрами типа string[n]. Понравится тебе? ты действительно думаешь, что все прогрессивное человечество крутящее базы на ораклах, мссклях, мускулях и постгресах уже давно отказалось от ограничений на длину строки и юзают исключительно безразмерные типы? Смею тебя заверить, все с точностью до наоборот. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2014, 10:19 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
NickDee Код: sql 1. Размер одной записи выборки около 32 килобайт. Чтобы посортировать миллион таких в памяти, нужно около 32ГБ памяти.Ты бы проверил вот это: Код: sql 1. Ну да, тут будет два раза обращение к `t`, но тем не менее сортировка потребует (20+4+4)*1'000'000 байт - 20=заголовок записи, 4 байта на id, 4 байта на timestamp (или 3 ?). ЗЫ. Ну и про спецбилд от ДЕ, где сортировка делается примерно так, как показано, но только соединение там идёт по rdb$db_key, - ты в курсах, конечно, и тестировал его ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2014, 10:27 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
Таблоид, Код: sql 1. поправил. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2014, 10:31 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
dimitr, Так что мешает? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2014, 10:31 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
NickDeekdvNickDee, гнусный ты провокатор. Да просто с такими удобствами вы весь userbase растеряете.Здесь на скуле, Джудж не хочет новый раздел создавать, пока не соберется определенное минимальное количество тем или желающих. (А уж создать раздел в тыщи раз легче, чем новый функционал сервера.) И ничего, не уменьшаются юзеры. Да, в принципе, чем больше возможностей, тем лучше. Только совершенно очевидно, что сначала надо делать более востребованные возможности, а потом - менее. А твоем случае, например насчет безрармерного varchar-a я не вижу каких-то особых причин его вводить, кроме банального "мне лень подумать, какие варчары будут тут и там, и легче лепить везде одно и то же. А потом поныть про проседание производительности". То же и со сверхдлинными числами. Неплохо бы привести пример, в какой области они будут использоваться (именно сверхдлинные, а не, скажем, длиной в 36 позиций). А то я например знаю только одну область, и там базы данных - нечто совсем постороннее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2014, 10:46 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
Cobalt747, здравый смысл. Ограничение длины - это констрейнт, который в большинстве случаев вполне успешно завязывается на бизнес-логику. Исключения бывают, конечно же, но раздувать из этого истерику в стиле "шеф, все пропало!" глупо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2014, 10:47 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
NickDeeПопробуй в Delphi закодить бизнес-логику на процедурах с параметрами типа string[n]. Молодой, длинные строки появились впервые в Delphi 2. До этого весь мир десятилетиями жил на строках с ограничением размера и не жужжал. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2014, 11:52 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
Засрали тему, ироды. Скопипастю, чтобы не затерялось: Гаджимурадов Рустам> Alexander A. Sak> Как постепенно уходящий от FB в Postgres Можно поподробнее на эту тему? Причины, описание самого процесса (с перечнем технологий и библиотек, если несложно), впечатления и пр. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2014, 13:51 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
Я помню. Времени не было подумать. Ну вот подумал. Основной мотив -- попробовать новенького. Остальное, наверное, вторично. Как это было у меня. Клуб анонимных отказников от Firebird. Начиналось все лет 13-15 назад. Основная БД была Оракл, разработка клиента -- Delphi. Попутно был левый проект -- приемная комиссия ОмГПУ. Программа выросла из штанишек Клариона, потом из штанишек Парадокса. На что переходить? Вариантов при тотальной Win98 не было: только Firebird. Пару лет даже жили с сервером на Win98. Клиента, которого делал на основной работе адаптировал под Firebird. Пошел мегапрофит: для левого проекта писать на Delphi не надо, все решалось исключительно настройками и хранимыми процедурами. Если возникали какие-то потребности, дорабатывался клиент на основной работе. Начальство было в курсе и было совсем не против. Потом появился второй левый проект: СПИД-Центр. Там все аналогично: клиент все тот же, системная серверная часть перекочевала из приемной комиссии. В 2006 уволился с основной работы. На новой -- все тот же Оракл и ничего кроме него. Левые проекты продолжались, но уже вяло. Потом на основной работе начался проект на джаве, началось погружение в JEE. Delphi совсем ушел на задний план. Года с 2009 в моем окружении стал пропадать Виндовс. В 2011 закончился СПИД-Центр: их возможности совсем перестали пересекаться с моими желаниями. В 2013 закончилась приемная комиссия ОмГПУ: начальство решило, что 1С -- решение всех проблем. В 2013 же взялся за замену 1С в магазине, занимающимся мебельной фурнитурой. Почему так -- тема другого поста, наверное. Итак 2013 год. Винды нет нигде, даже в магазине мебельной фурнитуры. Там везде Убунта. Я уже лет 7 не занимаюсь Delphi. Новый проект. Чем в такой ситуации Firebird лучше, чем Postgres? Был дан ответ: ничем. Оба устанавливаются одним чекбоксом, заказчику PG даже кажется более правильным выбором, у меня есть желание покачать скилл по новой БД. Плюс на основной работе начальство озаботилось стоимостью лицензий на Оракл и решило часть нагрузки перенести на PG. Тоже в кассу оказалось. Вот так я и очутился в стане пользователей Постгреса. Стоит отметить, что в выборе PG<=>FB еще повлияло наше сообщество FB. Какое-то оно повышенно снобистское что ли. Единственный человек, кого это утверждение на 100% не касается -- Дима Еманов. Такое впечатление сложилось еще со времен NNTP-рассылки. Не помню уже даже где она была. На Epsilon? Google? Помню, ловил себя несколько раз на мысли, что если бы знал, что завсегдатаи такие грубияны, поискал бы что-нибудь другое. Просто из вредности. Когда пришлось выбирать, это тоже сыграло какую-то роль. Спасибо за внимание. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2014, 20:08 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovNickDeeПопробуй в Delphi закодить бизнес-логику на процедурах с параметрами типа string[n]. Молодой, длинные строки появились впервые в Delphi 2. До этого весь мир десятилетиями жил на строках с ограничением размера и не жужжал. Двести лет назад электричества не было. И "удобства" были во дворе, когда там минус 40. Кто-то жужжал? И без компов обходились. Скажи лучше как мне универсально для строк задекларировать функцию Quote(S), которая бы квотила мне S. Сейчас получается вот такая гадость: Код: sql 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. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. Зы: понятно что правильный квотинг должен быть не просто слева и справа, но и с задваиванием символа " внутри строки. Но это уже к сути не относится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2014, 21:48 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
NickDeeкак мне универсально для строк задекларировать функцию Quote(S), которая бы квотила мне S. Вопросы "как мне правильно вырвать гланды через задницу" должны оставаться без ответа. Дабы не поощрять. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2014, 22:13 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
Alexander A. Sak> Я помню. Времени не было подумать. Ну вот подумал. > > Основной мотив -- попробовать новенького. Остальное, наверное, вторично. Спасибо. Хотя это вовсе не то, что интересно было услышать... > Там везде Убунта. Новый проект. Чем в такой ситуации Firebird > лучше, чем Postgres? Был дан ответ: ничем. Т.е. никакого выбора, фактически, не было, сменили даже не на "новенькое", а на "другое". Желание изучить новую тенологию, продукт и пр. похвально, конечно, но не как аргумент выбора. > Стоит отметить, что в выборе PG<=>FB еще повлияло наше сообщество FB. Есть такое дело, хотя преувеличивать нет смысла, да и вряд ли у PG c этим лучше (особенно по некоторым критериям). В любом случае, на фидбек и работу с СУБД это мало влияет. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2014, 22:13 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
NickDee, такую функцию не стоит объявлять, проще прям в запросе присоединить кавычки. Даже если не думать о том что строки как то там заполняются, то на просто на вызовах функций всё равно потеряешь производительность. В принципе я согласен с тобой в том что для процедур и функций длина строки могла бы вычисляться, в прочем как и точность numeric. Но ещё раз повторяю это задача не самая приоритетная. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2014, 22:14 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
Симонов Денистакую функцию не стоит объявлять, проще прям в запросе присоединить кавычки. Попобуй заквотить строку: А","B Должно получиться "А"",""B", а не "А","B". Так что универсально только функцией. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2014, 22:22 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovNickDeeкак мне универсально для строк задекларировать функцию Quote(S), которая бы квотила мне S. Вопросы "как мне правильно вырвать гланды через задницу" должны оставаться без ответа. Дабы не поощрять. По существу говори :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2014, 22:28 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
NickDeeПо существу говори :) Прикреплённая тема, ссылка дохлая, но всё же копий в сети как грязи: http://segfault.kiev.ua/smart-questions-ru.html#goal Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2014, 22:51 |
|
||
|
|

start [/forum/topic.php?fid=40&msg=38727658&tid=1563372]: |
0ms |
get settings: |
5ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
180ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
64ms |
get tp. blocked users: |
1ms |
| others: | 211ms |
| total: | 492ms |

| 0 / 0 |
