res = "\n".join( "%s - %s" % (n, v) for n,v in zip(names, forprint) if n )

Где?

clickhouse

это что вернет?

это что вернет?

Сорян, не res, а line у тебя это было

Это на пхп можно тяп-ляп и оно скушает )

clickhouse

Хз что это

Вообще null и пустую строку не просто так сделали

Это же разные вещи

Вообще null и пустую строку не просто так сделали

Скажи это ораклу

varchar2

Скажи это ораклу

Какой пиздец

Вообще null и пустую строку не просто так сделали

если очень нужен нул, то да, можно юзать, но зачем юзаь нул, если ты сам разрабатываешь софт и на 147% уверен в типе данных?

Вообще null и пустую строку не просто так сделали

Вообще если каких-то данных нет, то нуллы вместо них хранить не нужно

Какой пиздец

Да, мы тут мигрировали с оракла на постгрес. Было весело со строками

Вообще если каких-то данных нет, то нуллы вместо них хранить не нужно

В колонку ты что тогда запишешь?

res = "\n".join( "%s - %s" % (n, v) for n,v in zip(names, forprint) if n )

что это вернет

если очень нужен нул, то да, можно юзать, но зачем юзаь нул, если ты сам разрабатываешь софт и на 147% уверен в типе данных?

А если сам для себя то конечно как хочешь можешь делать в принципе

что это вернет

Твою строку line сформирует как ты просил

Твою строку line сформирует как ты просил

нет

А если сам для себя то конечно как хочешь можешь делать в принципе

даже когда писал на заказ, я то уверен что в эту еб* ячейку нельзя!!! записывать ничего кроме String или Float64 или Int8

оно же не подставит название полей

В колонку ты что тогда запишешь?

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

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

Нет. Но у тебя количество полей фиксированное. Ты не можешь не хранить ничего. Или отсутствие значения (нулл) или значение

даже когда писал на заказ, я то уверен что в эту еб* ячейку нельзя!!! записывать ничего кроме String или Float64 или Int8

А если сам для заказчика который согласен с тем что ты делаешь или ему похуй то можешь делать в принципе

оно же не подставит название полей

Names - названия. Пропиши их

А если сам для заказчика который согласен с тем что ты делаешь или ему похуй то можешь делать в принципе

Софт не падет, не глючит и тд? Ок? ок

Нет. Но у тебя количество полей фиксированное. Ты не можешь не хранить ничего. Или отсутствие значения (нулл) или значение

Это если схема не допускает. Но по-моему схема данных у вас немножко не того

Софт не падет, не глючит и тд? Ок? ок

Ну это пока

Ну это пока

попробуй убеди меня в обратном

даже когда писал на заказ, я то уверен что в эту еб* ячейку нельзя!!! записывать ничего кроме String или Float64 или Int8

Ладно. Я склонен согласиться, что в 99% случаев по логике null и пустая строка синонимы

Это если схема не допускает. Но по-моему схема данных у вас немножко не того

А мы не про реляционные бд сейчас?

А мы не про реляционные бд сейчас?

А в реляционных по-твоему нет понятия схемы?

А в реляционных по-твоему нет понятия схемы?

А что, схема реаляцилнных бд позволяет сделать таблицы с переменным числом полей?

попробуй убеди меня в обратном

Убедить тебя в том что система про которую я знаю только то что там в какую то ячейку всегда будут не нулябельные строки или ещё какая то ебала записываться, после дальнейшей разработки, после масштабирования и изменения внешней среды и прочих катаклизмов будет сохранять в себе это свойство?

Шта

Или ты предлаешь хранить в виде key, value, item id?

Убедить тебя в том что система про которую я знаю только то что там в какую то ячейку всегда будут не нулябельные строки или ещё какая то ебала записываться, после дальнейшей разработки, после масштабирования и изменения внешней среды и прочих катаклизмов будет сохранять в себе это свойство?

Если это мое приложение или поддерживаемое мной, то будет сохранять это свойство

Names - названия. Пропиши их

Хы, код то ему не очень подходит (ибо как я поняла у него значение может отсутствовать в любом месте, а ЗИП лишь порежет концы списка пока они по длине не станут равными)

Хы, код то ему не очень подходит (ибо как я поняла у него значение может отсутствовать в любом месте, а ЗИП лишь порежет концы списка пока они по длине не станут равными)

Там if же

Если это мое приложение или поддерживаемое мной, то будет сохранять это свойство

И ты будешь класть любые ресурсы только чтобы оно и дальше сохраняло это свойство?

И из проекта не уйдешь пока не умрёшь?

А когда умрёшь то твои дети унаследуют его?

Норм тема

И ты будешь класть любые ресурсы только чтобы оно и дальше сохраняло это свойство?

проект то мой. И зачем все это, если окружение будет одно всегда (да, возможно версия Бд поменяется, но вряд ли что-то серьезное случится)

т.е. типы как были стрингами такими и останутся

Там if же

В том то и дело что проверяешь не то поле хд

проект то мой. И зачем все это, если окружение будет одно всегда (да, возможно версия Бд поменяется, но вряд ли что-то серьезное случится)

вк тоже дуровский когда то был

В том то и дело что проверяешь не то поле хд

А. Гг. Конечно if v должно быть

вк тоже дуровский когда то был

и я ваще сисадмин. который в последние несколько лет пишет только софт для внутренних нужд (мониторинг, статистика/агрегация)... )

и я ваще сисадмин. который в последние несколько лет пишет только софт для внутренних нужд (мониторинг, статистика/агрегация)... )

Тогда какой заказ?

Тогда какой заказ?

года 4-5 назад

хотя и сейчас на пхп накидываю

А что, схема реаляцилнных бд позволяет сделать таблицы с переменным числом полей?

Главная таблица: type_id, type_name 1 "адрес" 2 "номер_телефона" Подчиненная таблица: 1(id записи) 1(id объекта Вася) 1(тип хранимых данных ) "ул. Пушкина дом Колотушкина" 2(id записи) 1(id объекта Вася) 2(тип хранимых данных ) "223 322 223 322" 3(id записи) 2(id объекта Петя) 1(тип хранимых данных ) "Дерибасовская 1" Итого мы храним переменное число полей с данными для Васи и Пети и можем добавлять новые типы данных Стандартная схема же

Лучше сразу писать в БД правильно, если нет данных то пустую строку а не null

Имхо решение хуевое, ибо нулы в бд занимают лишь бит

Главная таблица: type_id, type_name 1 "адрес" 2 "номер_телефона" Подчиненная таблица: 1(id записи) 1(id объекта Вася) 1(тип хранимых данных ) "ул. Пушкина дом Колотушкина" 2(id записи) 1(id объекта Вася) 2(тип хранимых данных ) "223 322 223 322" 3(id записи) 2(id объекта Петя) 1(тип хранимых данных ) "Дерибасовская 1" Итого мы храним переменное число полей с данными для Васи и Пети и можем добавлять новые типы данных Стандартная схема же

Ну я и говорю, key-value таблица. Это далеко не всегда удобно. Ради одного опционального поля городить никто не будет. А хуже если это поле - foreign key

Не видела ни одного архитектора бд который дефолтил ради избавления от нуллов

Имхо решение хуевое, ибо нулы в бд занимают лишь бит

не жалко

Не видела ни одного архитектора бд который дефолтил ради избавления от нуллов

Как же ты права этим утром...

Не видела ни одного архитектора бд который дефолтил ради избавления от нуллов

ну так я не тру дба-админ

а так, для вида )

Дефолтить к пустой строке ради того что бы писать не is null а != '' выглядит ещё тупее

Не видела ни одного архитектора бд который дефолтил ради избавления от нуллов

Дай ещё поныть. Создатели Oracle и их тип varchar2

ну так я не тру дба-админ

Факт то остаётся что ты используешь больше места чем можно для пустых значений

Ну я и говорю, key-value таблица. Это далеко не всегда удобно. Ради одного опционального поля городить никто не будет. А хуже если это поле - foreign key

Тогда страдай

Тогда страдай

Когда у тебя будет вся база из одной key value таблицы, страдать буду не я

Факт то остаётся что ты используешь больше места чем можно для пустых значений

всего-то 200 гиг весит

Имхо решение хуевое, ибо нулы в бд занимают лишь бит

Да и null это не пустая строка потому что null это полное отсутствие данных. Например удобно факт заполнения данных пользователем фиксировать

Когда у тебя будет вся база из одной key value таблицы, страдать буду не я

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

всего-то 200 гиг весит

Дай угадаю, ты еще не делаешь бэкапы?:)

Да и null это не пустая строка потому что null это полное отсутствие данных. Например удобно факт заполнения данных пользователем фиксировать

Ебушки воробушки. Пиздец да? Только ты это должен писать горе архитектору а не мне.

Дай угадаю, ты еще не делаешь бэкапы?:)

я написал свою систему для бэкапов на джанго+селери+редис+никс. утилиты хД

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

Тогда я не понимаю, с чем ты спросишь. Я сказал key value удобен не всегда, ты решил поспорить. А сейчас выясняется, что и сам не всегда юзаешь

Ебушки воробушки. Пиздец да? Только ты это должен писать горе архитектору а не мне.

мне то зачем? для моих задач можно и без него обойтись

я написал свою систему для бэкапов на джанго+селери+редис+никс. утилиты хД

Нудайбох воимя байтов.

Роботоит у миня роботаит атыбитись нахой

а то что погромисты пишут и как БД проектируют..

их проблемы

Да и null это не пустая строка потому что null это полное отсутствие данных. Например удобно факт заполнения данных пользователем фиксировать

Интересно как в ui отличить, не вводил пользователь данные или ввел и стёр

Интересно как в ui отличить, не вводил пользователь данные или ввел и стёр

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

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

Тогда я не понимаю, с чем ты спросишь. Я сказал key value удобен не всегда, ты решил поспорить. А сейчас выясняется, что и сам не всегда юзаешь

Я спорю с тем, что пихать в несколько полей неполные и опциональные данные - хорошая идея. Для опциональных полей чаще делают одно поле бд где их и хранят одной кучей в блобе например. А для важных делают более сложные схемы. Хотя до некоторого предела можно и опциональные хранитьв key-value, всё от требований к доступности данных зависит. В общем случае key-value значительно лучше, потому что для отдельныхболее важных полей можно создать view

Ну, можно сказать, что каждый проектирует софт/бд/етц в меру своей испорченности, я например пока не добрался до хайлоада в одном проекте, так что можно и так, в другой уже, и там уже надо заморачиваться, но для чем поле адрес отличается NULL от '' - разве что для того, чтобы легко сделать запрос и узнать реально ли не заполняли или просто добавили пустую строчку.

Я спорю с тем, что пихать в несколько полей неполные и опциональные данные - хорошая идея. Для опциональных полей чаще делают одно поле бд где их и хранят одной кучей в блобе например. А для важных делают более сложные схемы. Хотя до некоторого предела можно и опциональные хранитьв key-value, всё от требований к доступности данных зависит. В общем случае key-value значительно лучше, потому что для отдельныхболее важных полей можно создать view

key value хорош когда действительно много опциональных полей. И если не планируется их всегда запрашивать все вместе. Иначе ты сделаешь Вью, будешь работать только с ней, а под капотом окажется никому не нужная реализация с key value, которая ничего кроме тормозов индекса и необходимости поддерживать код вьюхи не принесёт

Либо если состав полей меняется часто и не хочется влезать в alter table

key value хорош когда действительно много опциональных полей. И если не планируется их всегда запрашивать все вместе. Иначе ты сделаешь Вью, будешь работать только с ней, а под капотом окажется никому не нужная реализация с key value, которая ничего кроме тормозов индекса и необходимости поддерживать код вьюхи не принесёт

Окей, тебе виднее. Мой опыт вынуждает меня оставаться при своем мнении. Мне не приходилось встречать ситуаций когда новые типы опциональных полей не только не добавлялись но и уничтожались вместе с ненужными данными

Видимо у тебя другая специфика

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

В общем, проехали

Как там топик стартер?

как сделать так - что если в массиве нет какого то значения - оно бы просто не выводилось?

Разобрался?

Разобрался?

нет(

пока другое доделываю

нет(

Выше Маришка сказала, что у меня там ошибка. if v должно быть

что такое None? это не просто отсутствующие данные?

None - остутсвие значения переменной

а в чем разница?