объясните по базам данных

[Sulik]

Когда создаешь таблицу и указываешь тип поля varchar ему сразу отводиться место на диске или это происходит при занесении данных.
И вообще имеет смысл создавать такие поля или можно использовать text

 

[Mr_Max]

Имеет смысл почитать литературу.

 

[c0dex]

Sulik
Вот сам головой то подумать, записей в БД может быть миллионы и миллионы и под них сразу нужно "застолбить" по твоему место?

Различия между varchar и text описаны тут http://dev.mysql.com/doc/refman/5.0/en/string-types.html

 

[skryisli]

VARCHAR по производительности выигрывает. Ну а огран в 64м - это считай безлимит. Уж 64 метра текста ты явно в базу впихуивать не будешь.

 

[vovanium]

И вообще имеет смысл создавать такие поля или можно использовать text

Это из разряда зачем использовать чашку, если можно использовать ведро.

 

[Sad Spirit]

Это из разряда зачем использовать чашку, если можно использовать ведро.

Ваще-то в postgres'е varchar от text'а отличается только наличием ограничения по кол-ву символов. Поэтому вполне нормальная рекомендация, если нет заранее известных пределов длин строк, заводить текстовые поля как text.

 

[Sulik]

Sad Spirit
Но это только в postgres. я так понимаю?

 

[fixxxer]

Если ты про mysql, то в нем иначе, угу. У text/blob есть некоторое количество ограничений влияющих на производительность, читай в мане.

Но это уже вопрос по реализации мыскля, а не "по базам данных"

 

[Sulik]

fixxxer
т.е насколько я понял то если будет частые обращений в базу на mysql-e и таким путем пойти это не будет лучшим вариантом?
ман я прочел как и прочел статью про регулярные выражения аж дважды только не понял не хрена. хотя судя по комментам там люди и по 50 раз прочли чтобы что-либо понять. хоть и статья хорошая просто очень много информации сразу сложно воспринять. а там ее уйма.

 

[vovanium]

Ваще-то в postgres'е varchar от text'а отличается только наличием ограничения по кол-ву символов. Поэтому вполне нормальная рекомендация, если нет заранее известных пределов длин строк, заводить текстовые поля как text.

И что? В любом случае желательно выбирать минимально достаточный тип, а так с таким же успехом, можно сказать зачем юзать SMALLINT, лучше уж сразу BIGINT

 

[grigori]

vovanium чукчанечитатель?
в стандарте SQL типа smallint нет, в постгресе smallint почти ненужен, и в mysql есть прикол с индексом по smallint-полю
польза от smallint против integer неоднозначна

 

[Вурдалак]

в mysql есть прикол с индексом по smallint-полю

— какой?

 

[vovanium]

vovanium чукчанечитатель?

Это похоже ты сам о себе писал? Про минимально достаточный тип ты не заметил, но приколупался к SMALLINT... Какая разница что там есть в стандарте, если практически в любой СУБД есть целочисленные типы от 1 до 8 байт, и причем тут integer, если я писал о восьмибайтном целом числе...
Более того почитай вопрос ТС, он вообще не о нюансах производительности рассуждает, ему для начала нужно разобраться зачем вообще есть разные типы, а то будут потом для всех полей bigint и text юзать.

 

[grigori]

Вурдалак, однажды я обнаружил, что индекс для int и smallint в myisam - одного размера (про innodb не знаю).
Индекс большой таблицы-связки у меня как-то скушал в 2 раза больше памяти, чем размер файла данных на диске, и я понял, что памяти мне ВНЕЗАПНО не хватает, индекс надо нафиг выбросить, и толку от smallint - как от козла молока.

vovanium повторю вам всем еще раз другими словами: вопрос надо рассматривать для каждой СУБД и для каждого случая индивидуально

 

[Sulik]

еще вопрос в таблице MySQL
есть поле view(int)
мне необходимо его увеличить на 1.
для этого обязательно делать два запроса в БД сначала выбрать его значение потом увеличить и записать или есть возможность одним запросом?

 

[Вурдалак]

`view` = `view` + 1

 

[Sulik]

Вурдалак
ок спасибо

 

[Sad Spirit]

И что? В любом случае желательно выбирать минимально достаточный тип, а так с таким же успехом, можно сказать зачем юзать SMALLINT, лучше уж сразу BIGINT

Объясняю второй раз, простыми словами:
а) Единственное, чем отличаются в postgres'е типы varchar и text --- наличием лимита на кол-во символов;
б) Скорость работы с varchar будет (весьма незначительно) медленнее из-за проверки этого самого лимита;
в) Из вышесказанного следует, что особого смысла заводить поля типа varchar(255) --- с отфонарными лимитами --- вместо поля text нету.

Что касается smallint вместо bigint. Когда я был маленький и занимался сайтом, ныне известным как rabota.ru, мне пришло сообщение об ошибке от пользователя: он не мог завести в резюме один из пунктов опыта работы. А работал дядя директором крупного завода и проблема была с заполнением поля "кол-во человек в подчинении", сделанном как раз smallint'ом. 35000 человек в подчинении уже не помещалось...

Так что, vovanium, не спрыгивай с темы "зачем нужны отфонарные лимиты" на тему "зачем нужны разные типы". Кстати мыскль как раз славится убогостью набора типов, которая компенсируется извращениями вроде unsigned tinyint.

 

[grigori]

`view` = `view` + 1

Если нужен результат обновления, то

mysql_query('UPDATE table SET id=LAST_INSERT_ID(id+1)');
$current_id = mysql_insert_id();

transaction-safe feature (hack), прикрывающая отсутствие последовательностей

 

[vovanium]

Sad Spirit
а) где ты увидел что ТС спрашивает про Postgres. Судя по его уточнению на твою мессагу, Postgres его волнует как раз мало.
б) "весьма незначительно" понятие относительное
в) ну из твоих расуждений следует, что создатели всех СУБД - тупые раз вводят кучу ненужных типов данных, нужно было как в PHP сделать текстовые поля, числовые, и т.п., и чтобы они конвертились автоматом.

Что касается твоего сайта, то это недостатки планирования, причем тут типы данных, если ты не мог представить что в подчинении может быть больше народа? А если бы ты в поле input сделал ограничение на 4 символа, тоже mysql был бы виноват? А то, что ты не использовал unsigned, скорее говорит о слабых знаниях MySQL на тот момент, так как вполне очевидно, что отрицательным количество подчиненных не может быть. А с другой стороны я видел много довольно серьезных скриптов, в которых тупо все поля были INT или даже BIGINT, даже те в которых хранятся значения типа 0 или 1.
Вообще очень похоже, что у тебя не было паскальной школы, тогда бы особых вопросов по типах не было.