Вот. Наконец-то правильный коммент. Есть конторы, возят из Европы б.у. корпоративные ноуты, в основном Dell и Lenovo за очень адекватные деньги. Конторы разные, правильные возят в состоянии like new и дают полугодовую гарантию. Я так купил штук 5-6. Последний -DELL Latitude 5480 в состоянии нового (вообще муха не сидела). Специально с процессором HQ (не низковольтовым)
Оверхеда слоя трансляции может и не быть, если это сделано на достаточно низком уровне. Выше было сказано, что все это не конвертится в SQL для Pg. То есть синтаксический анализатор свой, оптимизатор возможно тоже. Тут скорее вопрос, чтобы багов не было.
На сайте только 2 кейса, СИНКО-БАНК (причем там написано, что они свой код перевели в синтаксис PostgreSQL, то есть уже не совсем то) и Московская биржа, и там нет ни слова, что использовался вариант , который мы тут обсуждаем, там чисто PostgreSQL. Вообще если начинать углубленно думать, то вопросов конечно масса.
Я правильно понимаю, что можно одновременно писать как процедуры в формате 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к это печально конечно.
Вот. Наконец-то правильный коммент. Есть конторы, возят из Европы б.у. корпоративные ноуты, в основном Dell и Lenovo за очень адекватные деньги. Конторы разные, правильные возят в состоянии like new и дают полугодовую гарантию. Я так купил штук 5-6. Последний -DELL Latitude 5480 в состоянии нового (вообще муха не сидела). Специально с процессором HQ (не низковольтовым)
Оверхеда слоя трансляции может и не быть, если это сделано на достаточно низком уровне. Выше было сказано, что все это не конвертится в SQL для Pg. То есть синтаксический анализатор свой, оптимизатор возможно тоже. Тут скорее вопрос, чтобы багов не было.
На сайте только 2 кейса, СИНКО-БАНК (причем там написано, что они свой код перевели в синтаксис PostgreSQL, то есть уже не совсем то) и Московская биржа, и там нет ни слова, что использовался вариант , который мы тут обсуждаем, там чисто PostgreSQL. Вообще если начинать углубленно думать, то вопросов конечно масса.
Спасибо. В целом примерно понятно.
Есть немного вопросов.
Я правильно понимаю, что можно одновременно писать как процедуры в формате 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к это печально конечно.