|
Насколько важно в БД использовать поля разных типов Date/bool/long/integer
|
|||
---|---|---|---|
#18+
Т.е. сейчас начал планировать "структуру полей". Смысл в чем. При работе с текстовухами я особо не парился и в куче переменных используются String где по логике могло бы быть Date или boolean, или integer Т.е. пример: дата хранится как string в формате: DD.MM.YYYY , при отображении я соблюдаю "культурность" и конветирую это как Date с (авто)поправкой на настройки виндов (National standard). Другой пример, читаю из файла заведомо число и проверяю его наличие как Len(string)>0. Плюс в БД еще длину String можно задавать up to 255 Я чего боюсь. Счас начну эти Date использовать, таже база на другой системе выдаст автоматом DD.MM.YYYY как MM/DD/YY. А у меня "по точкам" где-то MM и DD вычисляются. Т.е. где нибудь чегой-то сглючит самым непредсказанным образом. М.б. не париться и использовать везде "Текстовый" тип, ну где это очевидно не 255 а меньшей длины? Больше места займет? А намного ли (с т.зр. мировой революции), если скажем пусть даже по 1000(обычно на порядки меньше) строчек (10-12 полей) в 2-х таблицах Какие рекомендации? Потом еще не понял пока насколько проблема, просто вспоминаю из прошлого. Напр. там пустая строка TheStr="", а оно мне при запросах начнет выдавать какие-нибудь NULL и хорошо если не на русском. В Access вроде усмотрел "разрешить строки нулевой длины". Т.е. как этот момент переварить. В текстовухе я использовал структуру: parametr1=PARAM1;parametr2=PARAM2;parametr3=PARAM3; причем parametr1=PARAM1;parametr2=;parametr3=PARAM3; и parametr1=PARAM1;parametr3=PARAM3; //упоминание о parametr2 вообще отсутствует дает одинаковый результат parametr2="" Ну, т.е. есть о чем беспокоиться... Счас пока планирую/конструируб БД в Access2000, потом конечно сделаю "создать" на VB думаю целиком управление через ADODB чтоб не кашей как я это делал раньше для себя(типа одна и та же прога и DAO и ADO + первые попавшиеся контролы, и еще не дай бог объект Access туда же в кучу). ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2011, 23:37 |
|
Насколько важно в БД использовать поля разных типов Date/bool/long/integer
|
|||
---|---|---|---|
#18+
Дмитрий77, Не парься, используй правильные типы данных. При доступе через ADO ты получишь правильные данные в нужном формате. К примеру получишь дату в типе Date, вне зависимости от национального формата, тебе вообще об этом думать не надо будет. С NULL тоже не парься, без разрешения NULL тебе никто не вернет. Ну и, естественно, при правильных типах данных будет правильно работать сравнение (по интервалу чисел или дат в отборе), сортировка и, разумеется, индексы. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2011, 23:53 |
|
Насколько важно в БД использовать поля разных типов Date/bool/long/integer
|
|||
---|---|---|---|
#18+
Дмитрий77parametr1=PARAM1;parametr2=;parametr3=PARAM3; и parametr1=PARAM1;parametr3=PARAM3; //упоминание о parametr2 вообще отсутствует дает одинаковый результат parametr2="" это решается через значение по умолчанию ... |
|||
:
Нравится:
Не нравится:
|
|||
20.01.2011, 00:04 |
|
Насколько важно в БД использовать поля разных типов Date/bool/long/integer
|
|||
---|---|---|---|
#18+
Shocker.ProНе парься, используй правильные типы данных. При доступе через ADO ты получишь правильные данные в нужном формате. К примеру получишь дату в типе Date, вне зависимости от национального формата, тебе вообще об этом думать не надо будет. Я сейчас уже запарился. В качестве предварит. подготовки пишу тест-конвертер текст->таблица Например имеем Код: plaintext 1.
На англицкой системе оно это автоматом не проконвертит в Date. Ну осилил конечно... Т.е. конвертирую в строчку в дата/время формате текущей OS, на которую IsDate() точно выдаст true на тек. OS если там действит. были дата время пусть в русском формате. Попутно доперло что Date/Time лучше объединять в одно поле, чтоб потом сравнивать как вы говорите. Код: plaintext 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.
IsNumeric() => заполняем поле If len(str)>0 then=> заполняем поле итд итп etc. Но это так понимаю цветочки... Прога то не заточена на "правильные данные в нужном формате" на входе, нужно будет все места оч. аккуратно переписывать. txt->mdb это почище чем делать перевод Control 6 => Control 5 думаю будет. Аналогия в том что нельзя сразу все одним действом поменять. А здесь в отличии от Common Controls все еще и завязано друг на друга. Там хоть я их по одному расстреливал/менял до полного отказа от использования прогой 6-ки. Здесь видимо придется делать дублированные вставки и смотреть чего получается. Еще один момент слегка беспокоит. В текстовухе строчки идут сверху вниз, т.е. сверху самая свежая строчка, этот порядок никто не "портит". А БД "себе на уме" может почему-то переиграть и запихнуть ее в середину. В ListView мне боятся нечего, там своя сортировка по заданному полю использована. А вот какие-то алгоритмы могут использовать "оригинальный порядок добавления строк", т.е. хотелось бы чтоб он не менялся по желанию БД. Как быть? Или какое-то доп. поле придется мудрить... И как добавить новую строчку именно в First (верх таблицы) а не в End? Или это очень просто или это очень непросто...всмысле накладно Shocker.Proи, разумеется, индексы. . Это че еще такое? Звон слышал но не кушал. Если можно без отсылки к учебникам. В Access на вопрос об индексах при создании таблицы всегда нажимаю "нет, спасибо". Связей между разными таблицами в проекте не предусмотрено. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.01.2011, 06:05 |
|
Насколько важно в БД использовать поля разных типов Date/bool/long/integer
|
|||
---|---|---|---|
#18+
Дмитрий77пишу тест-конвертер текст->таблица Но это так понимаю цветочки... txt->mdb это почище чем делать перевод Control 6 => Control 5 думаю будет. ну это же однократная конвертация, в процессе обычной работы она, полагаю, не понадобится Дмитрий77В текстовухе строчки идут сверху вниз, т.е. сверху самая свежая строчка, этот порядок никто не "портит". А БД "себе на уме" может почему-то переиграть и запихнуть ее в середину. В ListView мне боятся нечего, там своя сортировка по заданному полю использована. А вот какие-то алгоритмы могут использовать "оригинальный порядок добавления строк", т.е. хотелось бы чтоб он не менялся по желанию БД. Как быть? Или какое-то доп. поле придется мудрить... Мудрить ничего не надо, все придумано до нас. Если не вдаваться сейчас в подробности нормализации - выучи одно простое правило - в каждой таблице должен быть КЛЮЧ - то есть уникальное поле, по которому однозначно можно идентифицировать запись. Поверь на слово, что это нужно делать всегда, если проект развивающийся, если даже кажется, что в нем сейчас нет необходимости, то это не значит, что она не возникнет в дальнейшем. Так вот. Делаешь первое поле в таблице "ID", ставишь тип данных Long (уже забыл, как оно там в аксессе называется - четырехбайтное целое) и указываешь ему в свойствах автоинкремент и назначаешь ключом. То есть поле АВТОМАТИЧЕСКИ будет последовательно нумероваться по мере заполнения таблицы. Да, в БД нет понятия последовательности хранения записей. Внутри БД они хранятся так, как удобней СУБД. А для тебя эта последовательность будет определяться полем ID. Дмитрий77 И как добавить новую строчку именно в First (верх таблицы) а не в End? Или это очень просто или это очень непросто...всмысле накладно Это зависит от целей. В принципе если цель - сортировка, то вводится специальное поле с номером сортировки и при запросе данных из БД ты просишь отсортировать именно по этому полю. Дмитрий77Shocker.Proи, разумеется, индексы. . Это че еще такое? Звон слышал но не кушал. Если можно без отсылки к учебникам. В Access на вопрос об индексах при создании таблицы всегда нажимаю "нет, спасибо". Связей между разными таблицами в проекте не предусмотрено. Представь, что у тебя есть справочник по физике - том 500 страниц. Представь, что у него нет содержания. Чтобы найти нужную формулу, тебе придется прочитать его (в худшем случае) ВЕСЬ, в среднем случае - 50%. И так каждый раз. На это уйдет, скажем, день. Если в справочнике есть оглавление, то на поиск нужной формулы у тебя уйдет минута. Разница во времени очевидна. Индекс в БД - это оглавление. Индекс НА НЕСКОЛЬКО ПОРЯДКОВ ускоряет выборку нужных данных из таблицы (засчет (достаточно небольшого) замедления записи в таблицу). Индекс нужен на полях, по которым будет осуществляться отбор, соединение таблиц, сортировка. Более-менее имеет смысл, когда в таблице от 50-ти записей. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.01.2011, 10:19 |
|
Насколько важно в БД использовать поля разных типов Date/bool/long/integer
|
|||
---|---|---|---|
#18+
Дмитрий77Т.е. сейчас начал планировать "структуру полей". ... Т.е. где нибудь чегой-то сглючит самым непредсказанным образом. М.б. не париться и использовать везде "Текстовый" тип, ну где это очевидно не 255 а меньшей длины?Это может быть важно с точки зрения скорости, удобства и надежности. Скорость - сравнение двух чисел записанных как integer происходит быстрее чем сравнение двух чисел записанных как текст. Удобство - числа, даты и тп, будут сортироваться в натуральном порядке а не в алфавитном. (то есть будет 1, 2, 10 а не 1, 10, 2) Надежность - если изначально разрешить хранить числа в колонке как текст, то никто не гарантирует что какая-нибудь сволочь не запишет в одну из строк таблицы какой-нибудь текст. Если ты объявил колонку числом - база просто откажется добавлять запись если задаются поля неправильного типа. С другой стороны, существуют (и прекрасно существуют) базы данных с изначально не типизированными полями. Например SQLite, там в поля можно писать все что угодно и никто особо не жалуется. Но это встраиваемая БД и с ней есть некоторая уверенность что клиент к базе будет только один - а значит и контроль типов можно вынести на клиента. Вывод: использовать поля разных типов - не абсолютно обязательно, но желательно. Особенно на первых порах, пока не научился чувствовать поведение базы данных. А если БД серверного типа и к ней могут быть много разных клиентов написанных разными людьми - жесткая типизация становится чрезвычайно необходимой. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.01.2011, 17:58 |
|
Насколько важно в БД использовать поля разных типов Date/bool/long/integer
|
|||
---|---|---|---|
#18+
Shocker.ProДмитрий77пишу тест-конвертер текст->таблица Но это так понимаю цветочки... ну это же однократная конвертация, в процессе обычной работы она, полагаю, не понадобится. Но ее полагаю правильно/культурно сделать на каждом компьютере при обновлении версии. А будет ли это китайский или американский пользователь мне знать не дано, я года 2 назад на датах накололся, типа инсталлятор вылетал в половине стран при сравнении дат файлов. Shocker.ProЕсли не вдаваться сейчас в подробности нормализации - выучи одно простое правило - в каждой таблице должен быть КЛЮЧ - то есть уникальное поле, по которому однозначно можно идентифицировать запись. Так вот. Делаешь первое поле в таблице "ID", ставишь тип данных Long (уже забыл, как оно там в аксессе называется - четырехбайтное целое) и указываешь ему в свойствах автоинкремент и назначаешь ключом. То есть поле АВТОМАТИЧЕСКИ будет последовательно нумероваться по мере заполнения таблицы. Да, в БД нет понятия последовательности хранения записей. Внутри БД они хранятся так, как удобней СУБД. А для тебя эта последовательность будет определяться полем ID. Ну, разумно, сделал пока через Access. Текстовуху (этап конвертации в БД) тогда разумно конвертировать снизу вверх, добавляться конечно будет условно вниз с инкрементом по ID, а запрашивать: Код: plaintext
Здесь сразу вопрос предварит. возник. Допустим exe работает с базой (считай непрерывно) Правильно понимаю, что один раз подключиться и один раз отключиться разумно? Код: plaintext 1. 2. 3. 4. 5. 6. 7.
А как быть с objRecSetOut.Open /close ? Каждый раз перегружать, как надо что то добавить/прочитать? Код: plaintext 1.
Я обратил внимание что если этого не делать, то допустим при добавлении записей даже через тот же сеанс objRecSetOut.Open уже будет нарушено ORDER BY ID DESC, не говоря о том, что строки могут (и будут) добавляться через другой "exe". Вообще казалось что objRecSetOut.CursorType = adOpenDynamic достаточно, но счас склоняюсь к мысли что лучше делать close/open перед каждым действием. И надо ли делать .Close ? Shocker.ProИндекс в БД - это оглавление. Индекс НА НЕСКОЛЬКО ПОРЯДКОВ ускоряет выборку нужных данных из таблицы (засчет (достаточно небольшого) замедления записи в таблицу). Индекс нужен на полях, по которым будет осуществляться отбор, соединение таблиц, сортировка. Более-менее имеет смысл, когда в таблице от 50-ти записей. Про оглавление понятно, но как это применить к моему случаю, чего оглавлять и какое поле делать индексом абсолютно не понятно. Думаю забить. White OwlВывод: использовать поля разных типов - не абсолютно обязательно, но желательно. Это может быть важно с точки зрения скорости, удобства и надежности. Ну, с использованием разных типов считайте что согласился, хотя в частности в этом будут "ягодки", ибо программа не заточена на настоящий момент на "правильные типы". White OwlНапример SQLite, Но это встраиваемая БД и с ней есть некоторая уверенность что клиент к базе будет только один - а значит и контроль типов можно вынести на клиента. Ну в данном случае у меня будет работать именно по этому "встраиваемому" принципу, хотя и решил брать mdb. White Owlникто не гарантирует что какая-нибудь сволочь не запишет в одну из строк таблицы какой-нибудь А вот об этом уже подумал. Вероятность что Access установлен и соблазн щелкнуть на базе и туда залезть велик. С одной стороны если "сволочь" разбирается, это может быть полезно. А с другой стороны если не разбирается, то с умным видом влезет, наляпает там чего нибудь, а потом прога будет глючить, а user кричать "не боботает" и права качать. Я ж не могу писать все защиты от всех дураков. Ну могу например сделать len(Dir (baza.mdb)) и если вдруг базы нет то воссоздать ее по шаблону. Могу проверить наличие таблиц, полей, хотя даже это делать-время тратить уж очень не хочется. Поставить пароль? Один на всех? Секретностей конечно нет... Привязать пароль к компьютеру? system ID. Этот ID сглючит не будучи записанным на бумажку, и в эту базу никто никогда уже не войдет. Ерунда... ... |
|||
:
Нравится:
Не нравится:
|
|||
20.01.2011, 19:18 |
|
Насколько важно в БД использовать поля разных типов Date/bool/long/integer
|
|||
---|---|---|---|
#18+
Дмитрий77Правильно понимаю, что один раз подключиться и один раз отключиться разумно? это да, как правило Дмитрий77А как быть с objRecSetOut.Open /close ? лично я добавления и обновления делал только с помощью Execute на коннекте. Для получения данных открываю рекордсет, обрабатываю, закрываю. Но в общем-то, надо смотреть на задачу. Дмитрий77И надо ли делать .Close ? при закрытии рекордсета рекомендую делать не только Close, но и Set Nothing, сталкивался с глюками при повторном использовании недеинициализированного рекордсета. Shocker.ProПро оглавление понятно, но как это применить к моему случаю, чего оглавлять и какое поле делать индексом абсолютно не понятно. Думаю забить. я же ведь написал, что именно, повторюсь: Shocker.ProИндекс нужен на полях, по которым будет осуществляться отбор, соединение таблиц, сортировка. Более-менее имеет смысл, когда в таблице от 50-ти записей. если ты знаешь, что будешь сортировать по полю OrdinalNo или отбирать часть данных по DateFrom - то эти поля и делаешь с индексом. Дмитрий77Поставить пароль? Один на всех? Секретностей конечно нет...Поставить пароль от долбо@бов. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.01.2011, 19:27 |
|
Насколько важно в БД использовать поля разных типов Date/bool/long/integer
|
|||
---|---|---|---|
#18+
Access2000? Почему именно он? Другого никак? Мне кажется, что ты усложняешь себе Жизнь. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.01.2011, 20:30 |
|
Насколько важно в БД использовать поля разных типов Date/bool/long/integer
|
|||
---|---|---|---|
#18+
Shocker.Pro, т.е. с Connection: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8.
А с Recordset Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9.
>Для получения данных открываю рекордсет, обрабатываю, закрываю. Ну это понятно и соответствует вышепреведенному >добавления и обновления делал только с помощью Execute на коннекте это как? в смысле пример кода а что, открыть рекордсет, AddNew, Update, закрыть рекордсет как приведено выше (как я делаю) не годится? или хозяин барин? >Поставить пароль от долбо Ну т.е. один на всех стандартный не особо засекреченный (типа спросят-скажу без проблем) ? ================== В принципе вот еще общий вопрос, это из области "не люблю OCX-ов" "хочу чтоб работало на всех OS/компьютерах", "беспокоюся об этом" У меня сейчас стоит ссылка на Microsoft ADO 2.5 Library (msado25.tlb) Там еще есть 2.6, 2.7, 2.8 // 2.0, 2.1 и т.п. Без разницы? Или разница есть? Надеюсь эту tlb не надо тащить за собой? В принципе я могу эту ссылку вообще убрать (с ней удобно коды писать в смысле "подсказок") и делать типа Код: plaintext 1. 2. 3. 4.
и будет работать, хотя и не все, напр. это ругнется Код: plaintext 1.
Насколько имеет смысл ссылку вообще убрать? Программу с mdb предполагаю распространять без доустановок mdac/jet. Предполагаю что на всех виндах от XP до 7 это есть по умолчанию "как надо" включая x64 (простой тест на чистой win7 x64 вроде не споткнулся). Поправьте, если что не так. Это существенно для меня. Бодаться с mdac-ами и 64-битностями желания нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.01.2011, 20:33 |
|
Насколько важно в БД использовать поля разных типов Date/bool/long/integer
|
|||
---|---|---|---|
#18+
timtimAccess2000? Почему именно он? Другого никак? Мне кажется, что ты усложняешь себе Жизнь. Чем усложняю? Потому что я с этими базами пусть слегка, но умею работать. 2-3 таблицы. Чем плохо? Не новую же систему баз ради этого изучать? А на текстовухах, не говоря о том что они чуть подтормаживают... Последнее время стало тяжело врубаться в "собственные алгоритмы", а еще тяжелее "добавлять поля", модернизировать функционал и т.п. Типа там подправил, здесь забыл. Поэтому вроде как решился, работы ведутся, пока предварительные. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.01.2011, 20:39 |
|
Насколько важно в БД использовать поля разных типов Date/bool/long/integer
|
|||
---|---|---|---|
#18+
Т.е. у тебя локальная БД + клиент=рабочее место, и 1 клиенту не важно какая база у клиента номер 2? Если так то да. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.01.2011, 20:48 |
|
Насколько важно в БД использовать поля разных типов Date/bool/long/integer
|
|||
---|---|---|---|
#18+
Дмитрий77 Так? Базу не задолбаю? Ну я делаю так. Потому что, получив рекордсет (а я, как правило, открываю его ForwardOnly, ReadOnly (это самый быстрый тип)), я либо перегружаю куда-то данные, либо обрабатываю их и получаю результат. Дальше рекордсет мне уже в связи с этим не нужен. Но, повторяю, зависит от задачи. Дмитрий77>добавления и обновления делал только с помощью Execute на коннекте это как? в смысле пример кода Код: plaintext
Дмитрий77а что, открыть рекордсет, AddNew, Update, закрыть рекордсет как приведено выше (как я делаю) не годится? или хозяин барин? Годится, но это дольше. Грубо говоря при Execute я задействую механизмы СУБД и не делаю лишних действий по открытию рекордсета. К примеру над MSSQL ADO проделает такую массу операций туда-сюда (вижу по трейсеру), что аж страшно становится, а с Execute будет выполнена единственная команда. (Впрочем, с MSSQL я работаю через механизм хранимых процедур, пример привел для наглядности) Дмитрий77>Поставить пароль от долбо Ну т.е. один на всех стандартный не особо засекреченный (типа спросят-скажу без проблем) ? ну да, я это и имел ввиду. Дмитрий77У меня сейчас стоит ссылка на Microsoft ADO 2.5 Library (msado25.tlb) Там еще есть 2.6, 2.7, 2.8 // 2.0, 2.1 и т.п. Без разницы? Или разница есть? Надеюсь эту tlb не надо тащить за собой? ADO 2.8 стоит в системе, начиная с XP Дмитрий77В принципе я могу эту ссылку вообще убрать (с ней удобно коды писать в смысле "подсказок") и делать типа CreateObject("ADODB.Recordset") Можешь, но нет смысла, библиотека есть всегда ... |
|||
:
Нравится:
Не нравится:
|
|||
20.01.2011, 21:14 |
|
Насколько важно в БД использовать поля разных типов Date/bool/long/integer
|
|||
---|---|---|---|
#18+
Shocker.Pro Код: plaintext
Осилил вот такую конструкцию для "добавить": Код: plaintext
1) Строчку с названиями полей через запятую 2) Строчку с VALUES для этих полей Потом рожать строчку для Execute, и чтоб всякие одинарные кавычки не потерялись и туды итп etc Жестокий синтаксис. Ну бог с ним, принцип понял. Shocker.ProДмитрий77а что, открыть рекордсет, AddNew, Update, закрыть рекордсет как приведено выше (как я делаю) не годится? или хозяин барин? Годится, но это дольше. Грубо говоря при Execute я задействую механизмы СУБД и не делаю лишних действий по открытию рекордсета. К примеру над MSSQL ADO проделает такую массу операций туда-сюда (вижу по трейсеру), что аж страшно становится, а с Execute будет выполнена единственная команда. Возможно вы правы. Видимо при работе с рекордсетом в рекордсет копируется вся таблица ну или громоздские куски как минимум. Вспоминается такая история. Использовал я собственную базу, лежала на компе, назовем его СЕРВЕР, в таблице напр. несколько тысяч строк, несколько нехилых полей в каждой (ну т.е. в парочке столбцов числа 255 порой и не хватало) Долбил ясно дело через рекордсеты с соседнего компьютера, назовем его КЛИЕНТ (был Win98, потом XP, не суть) через че попало: ADO,DAO, какие-то там Data-контролы. Короче в качестве сервера в разное время пытался использовать Win98, потом XP, потом методом тыка окончательно остановился на Win2003. Там проблема в чем была: локальные сетки (98,XP)->98 (98,XP)->XP очень медленные, а вот (98,XP)->2003 на порядок быстрее работает при той же конфигурации сети и том же компе-сервере, почему не знаю. Короче (98,XP)->(98, XP) какие-то запросы-ощущение было? он всю базу чтоль перекачивает по локалке... Замена СЕРВЕР=2003 проблему решило, ну меня устроило во всяк. случае, но все равно, от формы "живого запроса": эт когда набираешь текст, а он тебе сразу непрерывно рекордсеты в столбик выводит, я отказался, ибо тормозило все равно. Счас конечно компы современнее/быстрее и база на локальном компе, но тем не менее. Задача более простая, чем пример описанный выше, но сейчас требуется КАЧЕСТВО и НАДЕЖНОСТЬ, ибо наличие меня "рядом" не предполагается. Например ситуация когда после сбоя питания компа строчки вида ################# через Access вычищать, "сжатие и восстановление" тоже надо потом подумать, коды есть, но видимо придется заного разбираться... Если ваше "аж страшно становится" соответствует описанному мной примеру, то лучше конечно через execute по вашему методу. Shocker.ProADO 2.8 стоит в системе, начиная с XP ,библиотека есть всегда Успокоили. В общем, синтаксис тяжелый, работы много. Надо наверно уже хватит рассуждать, а итти "дело делать". ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2011, 00:38 |
|
Насколько важно в БД использовать поля разных типов Date/bool/long/integer
|
|||
---|---|---|---|
#18+
Дмитрий77Осилил вот такую конструкцию для "добавить": Код: plaintext
Обращу внимание сразу на два аспекта: 1) Если пишешь в текстовое поле значение из переменной или другого источника, обязательно удваивай апострофы в значении, причина понятна 2) С датой осторожнее, ее надо писать либо в американском формате (независимо от региональных настроек компа) и в решетках, как и в VB: Код: plaintext 1.
Дмитрий77Надо отдельно препарировать 1) Строчку с названиями полей через запятую 2) Строчку с VALUES для этих полей Ты легко можешь написать под это дело функцию, принимающую paramarray и формирующую строку (которая заодно будет автоматом определять типы данных и правильно их форматировать (дату, обрамлять текст в апострофы и задваивать и т.п.), а то и запрос выполнять. В принципе, всю работу с БД нужно обязательно куда-то инкапсулировать, а не разбрасывать по коду. Дмитрий77Возможно вы правы. Твое первое сообщение ко мне было на "ты", давай уж уберем официоз Дмитрий77"аж страшно становится" соответствует описанному мной примеру, то лучше конечно через execute по вашему методу. Я не люблю посредников и черные ящики, чем меньше их на моем пути, тем лучше. Я стараюсь по максимуму писать собственные классы и четко знать, как они работают. Насколько я делаю вывод из твоих топиков - ты тоже придерживаешься этого мнения. ADO - здоровый глючный черный ящик. Поэтому я использую минимум необходимых мне функций. Возможно кто-то из присутствующих не согласится с моим подходом - его право. Дмитрий77В общем, синтаксис тяжелый, работы много. Надо наверно уже хватит рассуждать, а итти "дело делать". Это с непривычки. Как сказал Белый Сов - надо "почувствовать" работу с СУБД - тогда станет легко и приятно. Вообще SQL - офигенно мощный язык. Реально единственным запросом можно заменить несколько страниц кода с циклами на процедурном языке. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2011, 01:11 |
|
Насколько важно в БД использовать поля разных типов Date/bool/long/integer
|
|||
---|---|---|---|
#18+
Shocker.Pro, >2) С датой осторожнее, ее надо писать либо в американском формате (независимо от региональных настроек компа) и в решетках, как и в VB: Достаточно String типа Код: plaintext
... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2011, 01:52 |
|
Насколько важно в БД использовать поля разных типов Date/bool/long/integer
|
|||
---|---|---|---|
#18+
Дмитрий77Shocker.Pro, >2) С датой осторожнее, ее надо писать либо в американском формате (независимо от региональных настроек компа) и в решетках, как и в VB: Достаточно String типа Код: plaintext
Вот-вот, ты не понял. Попробую еще раз. DateSerial возвращает типа Date (!!!!!) Конкатенируя его со строкой ты заставляешь неявно преобразовать его строку. Преобразование произойдет в соответствии с текущими региональными настройками (которые черт его знает, как юзер наворотил) Полученную строку ты отправляешь ядру СУБД, которая попытается преобразовать это обратно в типа Date. Насколько успешно это получится на произвольной машине и не перепутает ли оно месяц с числом - неизвестно (кроме того, а зачем, собственно заставлять СУБД заниматься дополнительными вычислениями). Отправляя дату так, как я показал (в решетках в американском формате) ты заведомо отправляешь ядру типа Date, ему не нужно думать о преобразовании и где там месяц, где число. А вообще, всегда во всех темах говорю - неявное преобразование - зло (так же, как отсутствие Option Explicit) ЗЫ: Дата в решетках - это прерогатива JET, большинство остальных СУБД понимают ANSI - там уж точно не перепутается число с месяцем. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2011, 09:44 |
|
Насколько важно в БД использовать поля разных типов Date/bool/long/integer
|
|||
---|---|---|---|
#18+
Shocker.ProНасколько успешно это получится на произвольной машине и не перепутает ли оно месяц с числом - неизвестно. Известно. Как я уже упомянал, 2 года назад я совершил грубую ошибку. Сравнивал даты нескольких системных файлов с одинаковым именем (драйвера) в русском формате на этапе инсталлятора. В течении меньше суток с "публикации" пришло три притензии(люди не поленились написать): две из Бельгии, 1 еще откуда-то. Ошибка была быстро осознана, был дан workaround "Перенастройте комп на ГЕРМАНИЯ на этапе инсталляции" и ошибка была мной быстро исправлена по "хитрому" методу точно как выше. За прошедшие 2 года я ни одной претензии не получал (случайно обойти инсталлятор как вы понимаете невозможно). Я этот "а-ля конвертер" использую и в самой программе для "регионального отображения" дата/время, т.к. "внутри" программа работает "по понятиям" - с русским уклоном. Т.е. если вам это интересно, дайте мне (не)рабочий пример где это сглючит(с указанием региональных настроек при которых сглючит). И я тогда с вами соглашусь и буду чесать свою тупую башку. Специально тратить время на то в чем не вижу необходимости, пусть даже это кажется безграмотным, не вижу смысла. У меня в кодах столько реальных "безграмотностей", что конкрентно это в моем понимании скорее высший пилотаж, чем прокол. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2011, 10:36 |
|
Насколько важно в БД использовать поля разных типов Date/bool/long/integer
|
|||
---|---|---|---|
#18+
Дмитрий77Shocker.ProНасколько успешно это получится на произвольной машине и не перепутает ли оно месяц с числом - неизвестно. Известно. .... Т.е. если вам это интересно, дайте мне (не)рабочий пример где это сглючит(с указанием региональных настроек при которых сглючит). И я тогда с вами соглашусь и буду чесать свою тупую башку. Специально тратить время на то в чем не вижу необходимости, пусть даже это кажется безграмотным, не вижу смысла. У меня в кодах столько реальных "безграмотностей", что конкрентно это в моем понимании скорее высший пилотаж, чем прокол.Тогда слушайся тех кто знает. Твой клиент будет перед посылкой команды конвертировать дату в текст соответственно настройкам клиентского рантайма. Сервер БД будет расшифровывать дату из текста в соответствии с настройками сервера. Несовпадение региональных настроек между сервером и клиентом - приведет к проблемам. Ты можешь гарантировать что настройки клиентского рантайма совпадают с настройками сервера базы данных? Если можешь - делай как хочешь. Но я тебе дам маленький намек: я таких гарантий дать не могу. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2011, 18:24 |
|
Насколько важно в БД использовать поля разных типов Date/bool/long/integer
|
|||
---|---|---|---|
#18+
White Owl, Он предполагает, что сервер - это джет, запущенные на его же машине (даже если файл удаленный). Может это и справедливо в данном конкретном случае, но делать так не стоит, когда без усилий можно сделать нормально ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2011, 18:34 |
|
Насколько важно в БД использовать поля разных типов Date/bool/long/integer
|
|||
---|---|---|---|
#18+
Shocker.ProWhite Owl, Он предполагает, что сервер - это джет, запущенные на его же машине (даже если файл удаленный). Может это и справедливо в данном конкретном случае, но делать так не стоит, когда без усилий можно сделать нормальноДа, я знаю что он именно на это надеется. Но это всего-лишь надежды а не гарантия. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2011, 18:45 |
|
Насколько важно в БД использовать поля разных типов Date/bool/long/integer
|
|||
---|---|---|---|
#18+
White Owl Твой клиент будет перед посылкой команды конвертировать дату в текст соответственно настройкам клиентского рантайма. Сервер БД будет расшифровывать дату из текста в соответствии с настройками сервера. Несовпадение региональных настроек между сервером и клиентом - приведет к проблемам. Ты можешь гарантировать что настройки клиентского рантайма совпадают с настройками сервера базы данных? Если можешь Клиенты - это несколько exe-прог, которые находятся в папке /proga, запускаются строго с текущего компа, но могут из под разных аккаунтов: например exe1-из-под Local System (as Service, контролирует и логирует чего происходит) а exe2 -из-под Current User (User с его интерфейсами в частности через красивый ListView+какие-то отдельные команды в базу типа удалить-запустить-добавить) БД находится на том же компе в папке /proga/Subfolder (proga можно менять, Subfolder -строго зашитое в программу имя) White Owl Да, я знаю что он именно на это надеется. Он не надеется, он именно на это рассчитывает и именно в этом хитрость. Тем не менее я Вас понял, если допустим захочу добавить функционал управления системой с другого компа/разрешить хранить данные на общем сервере и т.п., то да возникнут проблемы и придется копаться по новой, и никто не спорит и в грудь себя не биет. Впрочем, я не возражаю, иначе еще полгода буду строчить топики вместо чтоб прогу писать. Shocker.Proкогда без усилий можно сделать нормально Код: plaintext 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.
Вроде проверил на нескольких разных "регионах", хуже не стало. If Len(StartTime) > 0 ==If IsDate(regionalDateTime) == (нет информации о дата/время) ==поле не заполняется (пустое) Ну вроде все всех поняли и все должны быть удовлетворены. Токо если можно. Не направляйте меня к учебникам по VB-форматам дат. Книгу Евангелос Петрусос Visual Basic 6 я чесно проштудировал 10 лет назад почти до конца первого тома + DAO/ADO из второго тома(в комплекте с CD-ROM). Я например не могу отказаться от внутреннего формата Russian Time. C-шная прога (откуда большая часть данных берется)отдает мне строго и независимо от региона Date=22.01.2011 Time=15:16:22 Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
... |
|||
:
Нравится:
Не нравится:
|
|||
22.01.2011, 00:47 |
|
Насколько важно в БД использовать поля разных типов Date/bool/long/integer
|
|||
---|---|---|---|
#18+
Он не надеется, он именно на это рассчитывает и именно в этом хитрость.Это не хитрость, это вредная привычка. Чем меньше хитришь, чем больше правил соблюдаешь, тем меньше проблем потом имеешь. Этот закон применим не только в программировании :) ... |
|||
:
Нравится:
Не нравится:
|
|||
22.01.2011, 01:06 |
|
Насколько важно в БД использовать поля разных типов Date/bool/long/integer
|
|||
---|---|---|---|
#18+
Дмитрий77Клиенты - это несколько exe-прог, которые находятся в папке /proga, запускаются строго с текущего компа, но могут из под разных аккаунтов: например exe1-из-под Local System (as Service, контролирует и логирует чего происходит) а exe2 -из-под Current User (User с его интерфейсами в частности через красивый ListView+какие-то отдельные команды в базу типа удалить-запустить-добавить) БД находится на том же компе в папке /proga/Subfolder (proga можно менять, Subfolder -строго зашитое в программу имя)Совершенно не важно где они находятся. Каталоги хранения приложения на региональные настройки никак не влияют. Важно что это все разные процессы, а у разных процессов могут быть (а у процессов принадлежащих разным аккаунтам будут обязательно) разные настройки окружения. На настройки окружения накладываются настройки самой программы, на настройки программы накладываются настройки сеанса работы программы... В итоге, предсказать что именно будет происходить с конкретным процессом при использовании примитивных языковых функций работающих на основе настроек рантайма - нельзя. Поэтому если хочешь надежности, то либо используешь языковые функции не зависящие от внешних параметров рантайма, либо каждый раз жестко прописываешь эти параметры перед вызовом функции. Это общий принцип не зависящий от типа задач. Будь это работа с базой данных, с сетью, с текстами, с графикой, с ячейками в Экселе, да с чем угодно. Дмитрий77Тем не менее я Вас понял, если допустим захочу добавить функционал управления системой с другого компа/разрешить хранить данные на общем сервере и т.п., то да возникнут проблемы и придется копаться по новой,Да. Причем в этом случае проблемы основанные на региональных настройках возникнут стопроцентно. В идеале, лучше сразу закладываться на i18n и делать из расчета на мусор в головах юзеров могущих подправить настройки системы и программ под свои вкусы. Дмитрий77Я например не могу отказаться от внутреннего формата Russian Time.А нужно. И вообще, какая пользователю разница в каком формате дата хранится внутри компа? Пользователю главное чтобы на экране было в удобном виде. А это значит что единственным местом где даты (или числа) должны быть в локализованом виде это при выводе на экран. Все. Во всех остальных случаях, привыкай работать с бинарным форматом, а если так уж нужно пересылать данные между разными модулями своей системы как текст - то шли их в ISO с минимальным форматированием. Дмитрий77C-шная прога (откуда большая часть данных берется)отдает мне строго и независимо от региона .... и там я ничего менять не готов, отсюда GetMyRegionalDateTime, ибо точно известно что есть mm,dd, yyyy и hh,mm,ss.Ну вообще-то это не С-шная, а С++-ная прога и выдает она dd.mm.yyyy и hh:mm:ss, но если у нее такой вывод и ты ее не можешь поменять - придется жить с тем что есть. Чтение внешних данных это как раз то исключение когда все рекомендации по собственному выводу данных не имеют смысла :) ... |
|||
:
Нравится:
Не нравится:
|
|||
22.01.2011, 01:26 |
|
Насколько важно в БД использовать поля разных типов Date/bool/long/integer
|
|||
---|---|---|---|
#18+
White Owl, Ну с датами "за решеткой" считайте согласился, код выше, он пусть и с моими заморочками но в соответствии с "рекомендациями". Даты пусть будут Date (два поля у меня вместо 4-х текстовых), это мне будет полезно, потому что ф-ции типа "взять что-то с наименьшей датой" предполагаются. По поводу C/С++ кода. Короче молчу в тряпочку. >если у нее такой вывод и ты ее не можешь поменять ну почему же, тот кусок что привел и доступ есть, и более того это "мой личный кусок кода". Но рожал я этот кусок где-то сутки. Такие куски мне не легко даются. По идее теоретически неплохо чтоб и C++ в БД ходила, но ежли я счас буду еще это рожать, то это на очень долго сяду. Пытался тут год назад на C++ форум заглянуть на тему обмена данными между C++ и VB6, люди там злые и невежливые, нахамили друг другу и пока поставил точку, пусть простыми файлами друг друга закидывают, а весь интеллект на VB. Т.е. если что-то на C++ мной рожденное работает, то тормошить зря не хочу. С этим все. Но, по сути вопроса, все поля типа Long/Integer/Boolean, которые было накрутил, я заменил на текстовые ограниченной длины, в основном 5. Это не вопрос, это так сказать осознанное решение. Смысл в чем: в основном эти поля чисто информация из логов (сравнивать, сортировать и т.п. ничего не надо). Они могут быть вообще пустые , т.е. 0-по умолчанию никак не годится, должно быть "". На первом тесте (но на второй день), и хорошо что почти сразу я столкнулся с глюком, ошибки не происходила, но программа при экспорте в ListView лепила предыдущую строку несколько раз вместо текущей (где не могла сконвертировать эти Long в пустую строчку и переменная для ListView не заполнялась-использовалось предыдущее значение). Не желая накручивать себя еще больше, я просто заменил все на String. Тип данных=текстовый Обязательное поле=нет Пустые строки=да Значение по умолчанию <empty> Размер поля=5 (например, но если 0/1/пусто, то =1) Заполнение поля делаю очень просто: Код: plaintext 1. 2. 3. 4.
При запросе objRecSetOut!pole7 objRecSetOut!pole8 я всегда получу свою пустую строчку при отсутствии значения. "Счетчик" и Date я оставил. Вот думаю, что такое Сжатие Юникод Да/Нет . Русских тестов вроде в таблицах не предвидится. Есть только пара ситуаций:1) по email будет прислан файл с "Национальным" именем файла, ориг. имя отразится в одном из полей таблицы. 2) Юзер введет в другое поле "русский" текст, который правда C-шный модуль быстро переработает в иероглифы, но в базе он будет как "русский". На всяк. случай поставил "Нет". ... |
|||
:
Нравится:
Не нравится:
|
|||
22.01.2011, 05:28 |
|
|
start [/forum/topic.php?fid=60&msg=37072779&tid=2159038]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
26ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
59ms |
get tp. blocked users: |
1ms |
others: | 16ms |
total: | 143ms |
0 / 0 |