А подскажите, почему DISTINCT всёравно даёт повторяющиеся результаты? Хотя по идее ддолжны быть только уникальные.

может данные всё таки разные?

mysql> select linkedid from cdr4 LIMIT 10; +------------------+ | linkedid | +------------------+ | 1496319912.19088 | | 1496319761.19076 | | 1496319863.19086 | | 1496319811.19082 | | 1496319665.19036 | | 1496319729.19072 | | 1496319746.19074 | | 1496319685.19043 | | 1496319692.19047 | | 1496319685.19043 | +------------------+

ну дык

просто вывод такой из за округления

вьюха там с дистинктом

округли сам

до нужной точности

а не нужно написать select distinct

?

Есть огромная вьюха с дистинктом

create view cdr4 as select DISTINCT `ast_cdr_adaptive`.`linkedid` AS `linkedid`, .....

тогда попробуй написать что то типа round(ast_cdr_adaptive,4)

Кажется я понял

Щас дистникт по мультиполям идёт. И он вырезает все совпадения по нескольким столбцам, а надо, видимо, делать подзапрос с уникализацией только одного поля

просто вывод такой из за округления

Там ID а не число для округления

Что-то не могу соообразить как подзапрос сделать, в текущем запросе и так большое условие WHERE. А вариант с подзапросом нагуглился только такой https://stackoverflow.com/questions/16257890/limit-distinct-values-in-mysql

база mysql ?

Group by + count

select field1 ,field2 ,field3 ,field4 ,count (*) from foo group by field1 ,field2 ,field3 ,field4 having count (*) > 1

Тип такого

Вместо дисьинкт

Having лишний будет

Group by уже дает нужный результат

Если мускуль, можно вообще не парится и сделать group by 1 без count,

s

Привет всем! Нужна помощь по sql

И тебе не болеть. Пиши что у тебя

Есть документ с таким полем posting

мне нужно искать документ в базе имея ключ который лежит в key_auths

как запрос правильно составить?

Как и обычно по названию поля

ТИП данных строковый

т.е. оберни ковычками

нужно исать по всем спискам в списке key_auths

Привет! Кто знает варианты веб эмуляторов поведения популярных RDBMS? Нужно чтоб поиграться с разными конструкциями не разворачивая все на собственных мощностях.

sqlfiddle

всем привет. может мне кто-нибудь объяснить, почему считается, плохо использовать NULL в БД? т.е отталкиваться от полей с NULL?

про мускул речь

кем считается?

у нас на проекте типа сеньёр так говорит

всем привет. может мне кто-нибудь объяснить, почему считается, плохо использовать NULL в БД? т.е отталкиваться от полей с NULL?

Потому, что с ним много приколов разных, от ломания ключей, до рандомной неведомой хуиты. Погугли "список приколов нуля в sql"

ок, сейчас)

Потому, что с ним много приколов разных, от ломания ключей, до рандомной неведомой хуиты. Погугли "список приколов нуля в sql"

чтото дичь какаято гуглится по твоему запросу...

не понимаю всёравно. ты в структуре таблицы пишешь "дефолтное значение NULL", какие могут быть приколы? оно должно быть или NULL или содержать значение.... IS [NOT] NULL в выборке, да и всё...

не понимаю всёравно. ты в структуре таблицы пишешь "дефолтное значение NULL", какие могут быть приколы? оно должно быть или NULL или содержать значение.... IS [NOT] NULL в выборке, да и всё...

Оно долно либо быть либо нет. Зачем там нуль? Что бы индекс ахренел?

?

Не в этом дело. Ок, гугли "mysql index null value truebles"

Не в этом дело. Ок, гугли "mysql index null value truebles"

Troubles

зачем вам индексы по null?

зачем вам индексы по null?

Сексу хотят

очередная жопная архитектура?

вот вот

++

я не про индексируемые поля говорю

а типа например product_options_id поле, которое может быть а может и нет

я не про индексируемые поля говорю

А зачем там нуль то?

бля

а типа например product_options_id поле, которое может быть а может и нет

ну может и может, не может и не может

ERROR: S client not available

ну а как ты поймешь есть ли опции у продукта или нет

в чем проблема то?

опытные пацаны базарят, щито нелзя так, вот в чём проблема

ну а как ты поймешь есть ли опции у продукта или нет

Ну они либо есть. Либо нет. Какой смысл там именно null писать?

опытные пацаны базарят, щито нелзя так, вот в чём проблема

если БД позволяет, то можно

потомучто по дефолту

Что бы размер базы был побольше от null?

другое дело, что потом вам это Г разгребать

какое Г?

Что бы размер базы был побольше от null?

что?

на столько глубоко я не лез, конечно

разное, часто пробелмы начинаются при джойнах и когда надо подставлять что-то вместо null

вооо

наконец ближе к сути приехали)

наконец ближе к сути приехали)

Ну да. Сеньор идиот. И хотел обмануть

блин, я ж спросил, чтобы понять

ибо мне не аргумент "НЕЛЬЗЯ" както

а сеньёр объяснять не изволили

ну сеньор может и перегибают палку, но посыл в глубине верный

))

зависимость наличия null и касяков/ошибок прямопропорциональна

всё, теперь всё по своим местам

спасибо всем за разъяснения

sqlfiddle

данкешон

всем привет. может мне кто-нибудь объяснить, почему считается, плохо использовать NULL в БД? т.е отталкиваться от полей с NULL?

Никаких проблем с использованием NULL'ов нет, если только люди не знают что такое функциональные зависимости и отношения между сущностями. Если рассматривать product_options_id, то NULL в нем легко избежать, product(#product_id,...) , product_options(#op_id,#product_id(not null), option_attr1,...) и будет считататься, что опции продукта не может быть без самого продукта(аггрегация) , либо сделать many-to-many.

Будет left join и опять null ?

Добрый день! Есть sh-скрипт, который запускаю ежемесячно. В этот раз результатом вы полнения скрипта является файл нулевого объёма (пустой). В командной строке следующая информация: ERROR 3 (HY000) at line 2: Error writing file '/tmp/MY0nH3Kl' (Errcode: 28) Место на дисках есть. Что ещё может быть?

Сервер перезапускал. В логах следующее: