> зато по скорости заруливает!
ну давай еще о sqlite поговорим :)
> афтор же не упоминул в чем именно заключается продвинутость...
раз не упоминул значить продвинутость в комплексе: фичи + скорость, а не уметь хотя бы VIEW и на что то претендовать странно.
К тому же в ACID (мы же не guestbook-и пишем ?) режиме еще не однозначно кто кого заруливает по скорости.
хотя mysql хорощ для своих задач, правда в четверке они с лицензией подлянку сделали.
Спасибо, что про collate обьяснили, а то не знал. Данные будут сортироваться по collate той локали с которой создана база после конвертации строки из локали клиента в локаль базы. Потом результат конвертируется в локаль клиента.
>Спасибо, что про collate обьяснили, а то не знал. Данные будут сортироваться по collate той локали с которой создана база после конвертации строки из локали клиента в локаль базы. Потом результат конвертируется в локаль клиента.
;-)) одна и таже кодировка может иметь несколько collation. К примеру в latin1 шведская collation и стандартная collation отличаются порядком букв. А в германии приняты 2 разные collation. А есть еще датско-норвежская и испанская collation. (Это все в latin1)
>Спасибо, что про collate обьяснили, а то не знал. Данные будут сортироваться по collate той локали с которой создана база после конвертации строки из локали клиента в локаль базы. Потом результат конвертируется в локаль клиента.
локаль клиента??? Может кодировка? set client_encoding to 'win';
postgres самая продвинутая??? мда... эта хрень даже не позволяет выделять права на уровне реквизитов(колонок) нах такое счастье нада... mssql и то это умеет
> эта хрень даже не позволяет выделять права на уровне реквизитов(колонок) нах такое счастье нада... mssql и то это умеет
юзай VIEW, концепуально это даже более правильно
>> такое счастье нада... mssql и то это умеет > юзай VIEW, концепуально это даже более правильно а VIEW можно организовать, так что можно корректировать/вносить данные?
то ед спасибо за ссылку а это точно "концептуально правильно" ???? хех, мне - то нужно было что бы пользователь А мог изменять ВСЕ поля таблицы 1, кроме одного, а пользователь В только одно... в мсскл - решается на раз... а тут нужно создавать две вьюшки да еще и разные рули на инсерты и апдейты... концептуально... ничего не скажешь...
концептуально - т.к. при таком подходе вьюшки играют роль интерфейсов, для одной и даже 10 таблиц такой подход конечно выглядит избыточным, но при больших базах и когда разные люди делают базу и морду весьма полезен.