Я правильно понимаю, что можно одновременно писать как процедуры в формате MSSQL, так и обычного Pg?
Если процедура написана в формате MSSQL, то в ней нельзя уже использовать специфику Pg? Ну для примера LIMIT/OFFSET против LIMIT/FETCH NEXT?
Процедура в формате MSSQL это уже некоторая вещь в себе, то есть там нет какого-то промежуточного Pg-представления чтобы посмотреть во что там реально транслируется код?
Сейчас вообще что то с пленочными камерами странное творится, ценник с моей точки зрения неадекватный. Пошел на Авито, посмотрел, Canon EOS 1v - 100-200, ломаный - 40 т.р. Вот этот Никон F80 - от 10, а скорее 15 и выше.
Какой-то ретро бум, причем не только на фото, а и например на печатные машинки. Раньше их отдавали очень дешево, а сейчас где-то 10-20-30 тыс в зависимости от модели.
У меня Minolta Dimage Scan Dual IV. Мне нравится. Плюс ещё покупал софт VueScan. Может это и не совсем крутой сканер и начало выпуска 2004 год, но меня полностью устраивает. Покупал на Авито лет наверное пять назад за 15 тыс, сейчас глянул, один лежит за 24.
Не очень понял про проводки десятилетней давности. Там уже все закрыто давно. Всё корректируется сторнирующими проводками. Ладно там заключительные обороты, но это один месяц в конце года.
Обычно порядок колонок проектируется не просто так, а чтобы было единообразно (если например есть набор стандартных колонок типа id, name и т.п.), чтобы легко читалось (важные колонки в начале, разумная группировка колонок по смыслу и т.п.). А тут получится каша, работать с этим будет ну так себе... Хотя 10% при большом объеме это довольно много. В общем как обычно сплошные компромиссы.
Не-не-не. Про integer речи нет. С ними все норм. Речь про строки. Беда в том что 'aaa' || null = null. В теории типа да, все правильно-красиво, а в реальной жизни это жесть.
Кстати в Oracle как раз ситуация попроще, там null и пустая строка совпадают. Вот в pg и в ранних версиях mssql, пока они не сделали режим, это беда. Всё эти nullif и прочее. Там да, лучше not null.
Да, тут согласен, по любому специфика используется, и тот же limit offset в pg это спасение по сравнению с оракловыми подзапросами . Вопросы по совсем экзотике.
Не использование FK может быть вполне сознательное, нет требований по последовательности delete / update, хотя тут можно и deferrable использовать, можно использовать например минус вместо null, чтобы избавиться от nvl и is not null, включить всякие служебные значения которые не хочется тащить в базовую таблицу, проще всякие импорты, тестовые наборы данных и т.д и т.п. Но тут надо тогда делать как минимум системный словарь на уровне приложения, иначе разбираться в зависимостях это будет ужас , плюс будет тенденция замусоривания и потери целостности, надо делать отдельно процедуры/сервисы по проверке, и сама логика приложения более критична к написанию и отладке, поскольку проверка целостности перекладывается с бд полностью на приложение. Я проектировал и системы без FK, и с ними. Не сказал бы что система без FK это плохо, все зависит от того, насколько сознательно и хорошо сделано. Но сейчас в целом я бы все таки рекомендовал классический подход с FK.
Всё это хорошо (без иронии), но тут возникает философский вопрос. Вроде как с такими трудами уходили с MSSQL, Oracle, и тут привязываемся опять к конкретной бд. Да, вроде как на горизонте не видно альтернативы, но я бы аккуратно подходил к использованию нестандартных возможностей.
В 2009-м 100к это около 3000 usd, более -менее. Потом конечно при скачке курса в два раза, если не была долларовая зарплата, то не так быстро все восстановилось , но в 2018-м 100к это печально конечно.
Обычная вью сама по себе ничего не ускоряет, она прячет внутри себя детали запроса, все будет зависеть от того, что будет в результирующем запросе. Некий минус обычной вью в том, что раз она есть , то ее так просто не поправить, соответственно, могут быть проблемы с оптимизацией запроса, в котором эта вью участвует. Но вообще лучше особо сильно вьюхами не увлекаться, хотя при разумном использовании они снижают когнитивную сложность.
Насчёт мат.вью общий совет - по возможности не использовать, только если уж совсем деваться некуда. Лучше уж какая-то денормализация. Плюс тут все зависит ещё от конкретной СУБД.
Спасибо. В целом примерно понятно.
Есть немного вопросов.
Я правильно понимаю, что можно одновременно писать как процедуры в формате MSSQL, так и обычного Pg?
Если процедура написана в формате MSSQL, то в ней нельзя уже использовать специфику Pg? Ну для примера LIMIT/OFFSET против LIMIT/FETCH NEXT?
Процедура в формате MSSQL это уже некоторая вещь в себе, то есть там нет какого-то промежуточного Pg-представления чтобы посмотреть во что там реально транслируется код?
Сейчас вообще что то с пленочными камерами странное творится, ценник с моей точки зрения неадекватный. Пошел на Авито, посмотрел, Canon EOS 1v - 100-200, ломаный - 40 т.р. Вот этот Никон F80 - от 10, а скорее 15 и выше.
Какой-то ретро бум, причем не только на фото, а и например на печатные машинки. Раньше их отдавали очень дешево, а сейчас где-то 10-20-30 тыс в зависимости от модели.
Да не, Ilford где-то от 700. А вы какие имеете в виду?
У меня Minolta Dimage Scan Dual IV. Мне нравится. Плюс ещё покупал софт VueScan. Может это и не совсем крутой сканер и начало выпуска 2004 год, но меня полностью устраивает. Покупал на Авито лет наверное пять назад за 15 тыс, сейчас глянул, один лежит за 24.
Не очень понял про проводки десятилетней давности. Там уже все закрыто давно. Всё корректируется сторнирующими проводками. Ладно там заключительные обороты, но это один месяц в конце года.
Да, вот в этом и суть, другая когнитивная нагрузка. Всё таки читать код и писать это совсем разные вещи.
И в темпоральных таблицах более сложная логика поддержания целостности атрибутов время_с, время_по.
Обычно порядок колонок проектируется не просто так, а чтобы было единообразно (если например есть набор стандартных колонок типа id, name и т.п.), чтобы легко читалось (важные колонки в начале, разумная группировка колонок по смыслу и т.п.). А тут получится каша, работать с этим будет ну так себе... Хотя 10% при большом объеме это довольно много. В общем как обычно сплошные компромиссы.
Да, тут согласен, это штука не очевидная, на нее надо налететь, и потом главное не забыть.
Не-не-не. Про integer речи нет. С ними все норм. Речь про строки. Беда в том что 'aaa' || null = null. В теории типа да, все правильно-красиво, а в реальной жизни это жесть.
Да, я знаю. Но от этого не легче. Странно конечно что они не сделали режим, как интерпретировать пустые строки.
Кстати в Oracle как раз ситуация попроще, там null и пустая строка совпадают. Вот в pg и в ранних версиях mssql, пока они не сделали режим, это беда. Всё эти nullif и прочее. Там да, лучше not null.
Да, тут согласен, по любому специфика используется, и тот же limit offset в pg это спасение по сравнению с оракловыми подзапросами . Вопросы по совсем экзотике.
Не использование FK может быть вполне сознательное, нет требований по последовательности delete / update, хотя тут можно и deferrable использовать, можно использовать например минус вместо null, чтобы избавиться от nvl и is not null, включить всякие служебные значения которые не хочется тащить в базовую таблицу, проще всякие импорты, тестовые наборы данных и т.д и т.п. Но тут надо тогда делать как минимум системный словарь на уровне приложения, иначе разбираться в зависимостях это будет ужас , плюс будет тенденция замусоривания и потери целостности, надо делать отдельно процедуры/сервисы по проверке, и сама логика приложения более критична к написанию и отладке, поскольку проверка целостности перекладывается с бд полностью на приложение. Я проектировал и системы без FK, и с ними. Не сказал бы что система без FK это плохо, все зависит от того, насколько сознательно и хорошо сделано. Но сейчас в целом я бы все таки рекомендовал классический подход с FK.
Всё это хорошо (без иронии), но тут возникает философский вопрос. Вроде как с такими трудами уходили с MSSQL, Oracle, и тут привязываемся опять к конкретной бд. Да, вроде как на горизонте не видно альтернативы, но я бы аккуратно подходил к использованию нестандартных возможностей.
В 2009-м 100к это около 3000 usd, более -менее. Потом конечно при скачке курса в два раза, если не была долларовая зарплата, то не так быстро все восстановилось , но в 2018-м 100к это печально конечно.
Обычная вью сама по себе ничего не ускоряет, она прячет внутри себя детали запроса, все будет зависеть от того, что будет в результирующем запросе. Некий минус обычной вью в том, что раз она есть , то ее так просто не поправить, соответственно, могут быть проблемы с оптимизацией запроса, в котором эта вью участвует. Но вообще лучше особо сильно вьюхами не увлекаться, хотя при разумном использовании они снижают когнитивную сложность.
Насчёт мат.вью общий совет - по возможности не использовать, только если уж совсем деваться некуда. Лучше уж какая-то денормализация. Плюс тут все зависит ещё от конкретной СУБД.
Да, с дальномером было лишнее. Не хотел их обидеть.
Переходник у меня есть с Y/C на Fuji-X правда там фокусное увеличивается на 1.5, но это не супер страшно.
Кстати, есть приложение для Android (возможно и для айфона тоже) - Hypocam.
Чисто для ч.б. съемки, очень стильное с кучей фильтров (правда многие платные) в том числе под разные виды пленок - Kodak TMax и т.п.