|
|
|
Новый проект. О чем нужно заботится заранее?
|
|||
|---|---|---|---|
|
#18+
Начинается новый проект. Есть ли какие-либо вещи, о которых нужно сразу позаботиться? Поскольку с ASA я знаком мало, то в голову приходят только 1) вопросы совместимости, например с ASE 2) вопросы, свзязанные с репликациями. Совместимость меня не заботит, т.к. в обозримом будущем миграция на другие сервера не предвидется, а репликации возможно придется реализовывать. В качестве первичного ключа очень удобно использовать identity , не возникнет ли в дальнейшем проблем с репликациями? Можно использовать в качестве PK GUID, но с ним неудобно работать. Какие еще меры нужно предпринять сейчас , чтобы потом безболезненно настроить репликации? P.S. Репликации, наверное, нужно в FAQ добавить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2004, 13:46 |
|
||
|
Новый проект. О чем нужно заботится заранее?
|
|||
|---|---|---|---|
|
#18+
мне дали один дельный совет, которого я придерживаюсь - не использовать int в качестве ПК. Лучше использовать строку: например: create table z ( id char(36) primary key default uuidtostr(newid()), name char(50) ) id сгенрированные на данной по машине, согласно документации, не сгенерятся ни на одной другой машине в мире. авторМожно использовать в качестве PK GUID, но с ним неудобно работать. по-моему это оно и есть. Только несколько иной метод представления это двоичный, то что написал я - строка, которую легко копировать/вставлять. Что именно неудобно? Еще одни из граблей - репликация со условиями (тоже было в этом форуме). Если условие наложено на мастер-таблицу, скажем where office='russia', то подчиненные строки (у которых в мастер-таблице office<>'russia'), все равно попадут в репликацию. Но foreign key не даст вставить. Приходится самому описывать "условия попадания в реплику" в виде тригеров, что очень неприятно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2004, 15:07 |
|
||
|
Новый проект. О чем нужно заботится заранее?
|
|||
|---|---|---|---|
|
#18+
автормне дали один дельный совет, которого я придерживаюсь - не использовать int в качестве ПК. А чем плох BIGINT и GLOBAL AUTOINCREMENT ? (это я не к тому, что он хорош, а к тому, что я просто не знаю подводных камней, в BOL во всяком случае его рекомендуют). P.S. Нашему FAQ явно не хватает раздела по репликации, хочу заметить, что этого нет ни в одном FAQ других СУБД. Может быть кто уже кушал репликацию и готов поделиться информацией в любом виде ? Было бы здорово первыми выложить информацию в этот раздел :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2004, 15:35 |
|
||
|
Новый проект. О чем нужно заботится заранее?
|
|||
|---|---|---|---|
|
#18+
Я, как типичный Плюшкин, люблю чтобы все было про запас. :) Поэтому я как-то сел и посчитал для своей задачи: если преположить, что юзер забивает в среднем каждую секунду лимон записей (знаю, такого не бывает), то моя прога будет жить 3 тыс. с копейками лет. :) Нет пирамиды переживать я не хочу, но если обратиться к простому int, то для 1000 записей в секунду - ресурс крайне не большой. Особенно если начинать это делить на количество точек, участвующих в реплике... Не очень хочется, чтобы потом тебя вспоминали ласковыми словами :). К тому же чингиз писал о каком-то глюке, при котором у него целочисленные айдишки раздавались криво - т.е. две точки сгенерировали одно и то же число. Bigint - хорошая штука, но есть одно но - не все клиенты корректно понимают Bigint. Есть какие-то ограничения. А чего я не люблю - неожиданностей. Особенно когда проект капитально вырос. Все это ИМХО. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2004, 15:47 |
|
||
|
Новый проект. О чем нужно заботится заранее?
|
|||
|---|---|---|---|
|
#18+
Ну мне в этом плане легче - клиенты на PB, поэтому проблем с BIGINT-ом по умолчанию не будет. А например, в проекте "Расчет зп" вообще одни INT идут, так как там по условиям задачи даже через 10 лет не может быть такого кол-ва записей, которое обеспечивает этот тип, а значит и переполнения. В этом плане у меня идет "перебор" как раз с хранением сумм - NUMERIC(15,2) (MONEY до сих пор не признаю, тяжкое наследие MSSQL), видно слишком четко у меня на предыдущих проектах в памяти 90-ые годы отложились и тут лучше перебздеть, а то мало ли, миллион записей в секунду юзеры вряд ли вгонять будут, а вот рубли в России могут в геометрической прогрессии нолики прибавлять :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2004, 15:54 |
|
||
|
Новый проект. О чем нужно заботится заранее?
|
|||
|---|---|---|---|
|
#18+
авторвот рубли в России могут в геометрической прогрессии нолики прибавлять :) :) понятно, правда до Турции России еще далеко (в плане нулей на купюрах) :) Исчо один совет: использование passthrough режима при репликации: лучше выполнять как можно более мелкими шагами, постоянно проверяя изменения, которые внесли, на удаленных базах. Это действительно одна из важных рекомендаций BOL. У меня однажды dbremote пропустил инструкцию, а после нее выполнил следующую (!). Было очень весело. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2004, 17:55 |
|
||
|
Новый проект. О чем нужно заботится заранее?
|
|||
|---|---|---|---|
|
#18+
ASCRUS (MONEY до сих пор не признаю, тяжкое наследие MSSQL) Это к тому, что может не хватит разрядности money? Рыжий Кот, newid() как раз и возвращает GUID. Int по сравнению с ним имеет то преимущетво, что с ним легче на клиенте работать. Т.к. int 32 бита, то его удобно маскировать под указатели и хранить, например, в TTreeNode.Data. Также удобно формировать строку ИД-ников для дальнейщей фильтрации и т.д. Это я все про Delphi, но в других средах разработки, я думаю, можно также поступать. С int'ом в качестве PK проблем у меня никогда не было. А про исчерпаемость... Максимальное значение int: 2147483647. Положим, что в системе каждую секунду (для большинства задач это просто заоблачная частота вставки записи) будет генерироваться новый ИД. Тогда int'а нам хватит на 2147483647 сек. или 68 лет . Хм... если моя система будет работать 70 лет, тогда я по праву буду считать себя великим программистом ;) И все таки... как будут работать репликации, если PK будет int'ом? P.S. FAQ по репликациям действительно жизненно необходим. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2004, 19:01 |
|
||
|
Новый проект. О чем нужно заботится заранее?
|
|||
|---|---|---|---|
|
#18+
авторМаксимальное значение int: 2147483647. Положим, что в системе каждую секунду (для большинства задач это просто заоблачная частота вставки записи) будет генерироваться новый ИД. Тогда int'а нам хватит на 2147483647 сек. или 68 лет. Хм... если моя система будет работать 70 лет, тогда я по праву буду считать себя великим программистом ;) А теперь представь что у тебя 10 точек, из которых набиваются данные. Причем одна из них набивает со скоростью в 3 быстрее чем другие. Если выбирать int, то диапазон 2147483647 нужно разделить на 10. Т.е. Sybase сам отведет нужные пулы под каждую базу. и 70 лет сократится до 7 :). Дальше, один из диапазонов будет заполняться быстрее, так? значит 7 превращается :) в 3 или 2? А вдруг еще перед этим в систему нужно вкачать хорошее число данных?... определенно int не подходит. Lotus Notes (который по возрасту уже дедушка) изначально все построил на guid... Вся репликация идет на его основе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2004, 20:20 |
|
||
|
Новый проект. О чем нужно заботится заранее?
|
|||
|---|---|---|---|
|
#18+
А я, например, для организации репликаций использую технологию предложенную еще в 5 версии. Для генерации первичного ключа (уникальности) использую связку двух полей в таблице: cPubl (char(8) DEFAULT Current Publisher) + ID (double DEFAUL autoincrement) - никогда не подводила. Идентификатор любой базы - имя ее паблишера, никаких переполнений (пока). Все записи в реплицируемых таблицах известно откуда пришли. Единственное (недостаток) построение выборок по связанным таблицам для публикаций, но и это решаемо. Надо проверить возможность построения первичного ключа по вычисляемому полю. Если проканает, то тогда этот недостаток можно откинуть в сторону. Рекомендую. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2004, 20:57 |
|
||
|
Новый проект. О чем нужно заботится заранее?
|
|||
|---|---|---|---|
|
#18+
ASCRUS(MONEY до сих пор не признаю, тяжкое наследие MSSQL), видно слишком четко у меня на предыдущих проектах в памяти 90-ые годы отложились и тут лучше перебздеть, а то мало ли, миллион записей в секунду юзеры вряд ли вгонять будут, а вот рубли в России могут в геометрической прогрессии нолики прибавлять :) Не совсем понял если честно, почему тип money не нравится? Если мне память не изменяет (а она мне не изменяет потому как в BOL проверил :) ) В ASA предопределены два вторичных типа, money: NUMERIC(19,4) и smallmoney: NUMERIC(10,4) (реализованый как int/1000). Пятнадцать знакомест под целую часть это 999,999,999,999,999.9999... то есть вплоть до биллиардов можно хранить. Думаешь инфляция настолько подпрыгнет? :) А насчет FAQ по репликации - скажите какие вопросы там осветить, попробую написать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2004, 21:09 |
|
||
|
Новый проект. О чем нужно заботится заранее?
|
|||
|---|---|---|---|
|
#18+
Ну мне тип Money не нравился в MSSQL, потому как там он работал глюкаво и непредсказуемо. Так что я уже привык просто NUMERIC использовать и не заморачиваться. Насчет FAQ - в принципе было бы здорово собрать коллекцию статей по DBREMOTE и MobiLink, и там осветить проблемы работы этих репликаций через различные виды подключений, кто с какими глюками сталкивался и как их решал. Так же думаю, если на этом форуме будут активнее обсуждать проблемы репликации, то в конце концов список вопросов и ответов сам наберется. Ну и для начала можно просто вводные статьи - типа какие репликации в ASA поддерживаются, как они работают, в чем их преимущества и сила по сравнению с репликациями в других СУБД. Такое было бы полезно даже в плане рекламы на SQL.RU ASA - на всех СУБД информации по репликации кот наплакал, а для России это один из решающих показателей при выборе СУБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2004, 22:28 |
|
||
|
Новый проект. О чем нужно заботится заранее?
|
|||
|---|---|---|---|
|
#18+
Рыжий КотЕще одни из граблей - репликация со условиями (тоже было в этом форуме). Если условие наложено на мастер-таблицу, скажем where office='russia', то подчиненные строки (у которых в мастер-таблице office<>'russia'), все равно попадут в репликацию. Но foreign key не даст вставить. Приходится самому описывать "условия попадания в реплику" в виде тригеров, что очень неприятно. Эээ.. А использовать "..SUBSCRIBE BY .." и "UPDATE table PUBLICATION ..." для публикаций не подходит ? Рыжий КотК тому же чингиз писал о каком-то глюке, при котором у него целочисленные айдишки раздавались криво - т.е. две точки сгенерировали одно и то же число. Вот как раз сейчас борюсь с таким. У меня немного не так - генерятся ID без учета значения Global_database_id, как будто значение этой переменой =0. Насколько я понял это из-за "неправильного" выключения сервера. Сказали что в ebf3519 вылечили (ASA704), посмотрим... А вообще нужно изначально продумать эту ситуацию и пути ее решения. PS: а от перспективы использования PK GUID меня немного передергивает ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2004, 23:56 |
|
||
|
Новый проект. О чем нужно заботится заранее?
|
|||
|---|---|---|---|
|
#18+
ASCRUSНасчет FAQ - в принципе было бы здорово собрать коллекцию статей по DBREMOTE и MobiLink, и там осветить проблемы работы этих репликаций через различные виды подключений, кто с какими глюками сталкивался и как их решал. В общем эта... я тут попытался вспомнить какие тупые вопросы меня самого очень мучали при изучении процесса репликации :) Наскреб пока четыре штуки: 1) В чем разница между SQL Remote и DBRemote? 2) Можно ли настроить репликацию без dbxtract? 3) А что случится если во время сеанса репликации произойдет обрыв связи? 4) Настраиваю репликацию по FTP, в документации предлагается записать пароль доступа к FTP в регистри, это же кто угодно может прочитать?! Написал к ним комментарии, и отправил их тебе по почте в виде rtf-ки... Посмотри, если понравится, выкладывай в FAQ. ASCRUSНу и для начала можно просто вводные статьи - типа какие репликации в ASA поддерживаются, как они работают, в чем их преимущества и сила по сравнению с репликациями в других СУБД. Это не ко мне, я только один тип репликации делал пока. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2004, 00:14 |
|
||
|
|

start [/forum/topic.php?fid=55&msg=32553293&tid=2014440]: |
0ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
43ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
48ms |
get tp. blocked users: |
1ms |
| others: | 13ms |
| total: | 150ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...