Из всего этого можно заключить, что Lotus Notes/Domino - это гениальный продукт. Лишь бы IBM действительно его последовательно развивала и улучшала, а то был досадный период, когда всё затормозилось и будущее LND затуманилось.

 

В транзакциях особо нет. ... Если вероятность сбоя в момент внесения связанных изменений в разные документы очень мала, то транзакции ничего особо в этой ситуации не дали бы. ... Но, замечу, что поддержка транзакций тоже не дает 100% гарантии. Журнал транзакций может ведь тоже навернуться...

Блин.. как все запущено. Что такое транзакция ты просто еще (надеюсь) не знаешь (LND-шный "журнал" к транзакции никакого отношения не имеет)
К стати ссылочная целостность без транзакции невозможна

... В лотусе не сложно реализовать удобства РСУБД, а попробуйте реализовать репликацию на РСУБД... Я не пробовал, за то слышал много матов, от тех кто это пытался делать.

А тут у тебя путаница и штампы.

Я давеча "теорему" доказывал о несовместимости репликации и транзакции. СУБД можно научитьработать в распределенной среде (сделать репликатор), но она тогда потеряет транзакционность. И наоборот: к LND можно прикрутить транзакцию. Но она перестанет быть распределенной

 

Блин.. как все запущено. Что такое транзакция ты просто еще (надеюсь) не знаешь (LND-шный "журнал" к транзакции никакого отношения не имеет)
К стати ссылочная целостность без транзакции невозможна

Батенька, Вы никак глухой и слепой? Там русским языком написанно про DECS, точнее английским. Про ссылочную целостность ты написал полную чушь, уж извини :lol: Нашелся тут знаток доморощенный ))))) Извини, не сдержался ) Но нужно думать, что пишешь. У тебя есть документ, а в нем ссылка на второй. Второй удалили - ссылка в первом мертвая. Что делать? Не давать удалять документ, если на него ссылаются. Вот и вся ссылочная целостность. Далее уже твое дело, как ты будешь удалять ссылку и сам документ, хошь удаляй транзакционно, хошь по очереди. Как пример, 1С, справочник номенклатуры, попробуй там удалить продукт, на который есть ссылки в документах (например, в накладных или счетах). Не выйдет. Вот она и ссылочная целостность в работе. Как только ссылок нет, система удалит этот продукт.

 

Благодаря наличию связей в реляционной БД можно хранить данные об объектах в нормализованном виде. При этом данные об одном объекте хранятся в нескольких таблицах, связанных ссылками. Но выделить все записи, относящиеся к нужному объекту, можно только тогда, когда соблюдается ссылочная целостность.

Не понимаю почему проблема цылочной целостности друг встала в LND? Это все реализуется несколькими строками кода в зависимости от НОРМАЛИЗОВАННОСТИ данных хранимых в LND, а если нормализованности нет? Как прикрутишь эту целкостность? Да и не нужна она в этом случае, а так как лотус специализируется на ненормализованных данных поэтому нет и инструмента так необходимого в РСУБД. То же самое относится к транзакциям, только с той разницой, что транзакции в LND есть, но не в явном виде и не в той форме как в РСУБД. А то что в LND реализовывать транзакцию нужно вручную, это конечно неудобство, но не НЕВОЗМОЖНО. В лотусе можно реализовать все тоже самое что и в РСУБД потому что РСУБД являются частным случаем ООСУБД!

З.Ы. Хотя для честности, нужно признать, что РСУБД+сервер приложений XML веб сервисов = LND по возможностям и реализуемым функциям.

 

Батенька, Вы никак глухой и слепой? ...

Сэр, Вы хам и неуч. С Вами я более не общаюсь и другим отсоветую

Не понимаю почему проблема цылочной целостности друг встала в LND? .. Да и не нужна она в этом случае, а так как лотус специализируется на ненормализованных данных поэтому нет и инструмента так необходимого в РСУБД.
..
То же самое относится к транзакциям, только с той разницой, что транзакции в LND, но не в явном виде и не в той форме как в РСУБД. А то что в LND реализовывать транзакцию нужно вручную, это конечно неудобство, но не НЕВОЗМОЖНО.

По 1-му - поддерживаю. Специфика (и сила) LND - в заточенности под ненормализованные данные. Я не знаю, что было для Ирисов отправной точкой, но именно ненормализ.данные (документо-ориентированная база) позволили создать реальную распределенную среду.

Со 2-м: я все-ж трактую транзакционность по-СУДБшному - как атомарность операций над группой независимых сущностей (рекордов в СУБД, документов и вьюх - у нас). Такого в LND нет, и в распределенной среде по определению быть не может: Один док-т на одном сервере, второй - на другом. И связи СЕЙЧАС нет. Ы? Реплика не спасает, т.к. пока нет связи эти док-ты там проучаствуют в других "транзакциях".
Или: 2 док-та в одной базе. Транзакция -> они модифицируются синхронно. Ок. А теперь эта база реплицируется на другой сервер. Где гарантия, что оба док-та уйдут туда одним сеансом??

 

Constantin A Chervonenko
Зато если связь сейчас есть, и канал более-менее широкий, то обычный MS Sql вполне позволяет сделать transactional replication with updating subscribers c immediate updating для выбранных таблиц. И будут все плюшки РСУБД: атомарные транзакции, ссылочная целостность...

 

Сэр, Вы хам и неуч. С Вами я более не общаюсь и другим отсоветую

О, испугал :lol: Ты посмотри, как сам общаешься, как индюк напыщенный, как-будто вокруг тебя одни дураки. Кстати, ничего по конкретике так и не смог ответить, отмазался обидой

Не понимаю почему проблема цылочной целостности друг встала в LND? Да и не нужна она в этом случае, а так как лотус специализируется на ненормализованных данных поэтому нет и инструмента так необходимого в РСУБД.

Не совсем так. Дело не только в нормализации. Один документ может ссылаться на другой к примеру.

И нормализация в LND возможна штатными средствами (я уже не говорю про DB2, DECS и LEI). К примеру, таблицу в LND можно сделать в виде embedded view. При репликации, кстати, можно временно потерять часть "строк" этой таблицы или сам родительский документ. В РСУБД, если включен контроль ссылочной целостности при репликации, родительский документ (на который ссылаются другие) потерять нельзя.

Кстати, в РСУБД тоже когда-то не было поддержки ссылочной целостности, к примеру в IBM DB2 в 1989 г. появилась и в SQL это понятие не сразу было добавлено. Так что и у LND всё впереди ) Собственно, уже есть, при использовании DB2 это возможно. Либо при использовании другой РСУБД через DECS или LEI.

Достоинство Lotus Notes/Domino не в том, что в нем можно сделать ненормализованную БД (такую БД можно и в РСУБД сделать - без проблем!), а в том, что в LND можно сделать быстро полноценное приложение и быстро, буквально на лету, его менять, подстраивать под требования пользователей. Добавление в LND транзакций или ссылочной целостности никак бы не ухудшило LND как среду разработки, а только расширило бы её возможности! Собственно, что IBM и делает, молодцы!

 

Constantin A Chervonenko
Зато если связь сейчас есть, и канал более-менее широкий, то обычный MS Sql вполне позволяет сделать transactional replication with updating subscribers c immediate updating для выбранных таблиц. И будут все плюшки РСУБД: атомарные транзакции, ссылочная целостность...

Разумеется. Но при наличии канала отпадает надобность в репликации! Гораздо разумнее будет всегда получать достоверные данные из первоисточника, и править их там-же.
Я о том и талдычу: реально LND имеет преимущества именно в распределенной среде. А если канал позволяет, то данные следует централизовать. А если данные централизованы, то почему мы должны терпеть отсутствие транзакции, ссылочной целостности и далее по тексту. И что там от LND осталось? Документоориентированная база, заточенная под неструктурированные данные и потому удобная для быстрой разработки? Да, это кое-что. Однак новомодные пост-реляционные, non-1st-normal form, ООСУБД, XML базы не сильно отстают.
Этой молодой поросли Домина может противопоставить разве что цену (всё "в одном флаконе")

 

Разумеется. Но при наличии канала отпадает надобность в репликации! Гораздо разумнее будет всегда получать достоверные данные из первоисточника, и править их там-же.

В том то и дело, что не отпадает. Если данных много, если меняются они реже, чем выбираются (обычно так и происходит), если канал стабильный, но не сверхширокий, то выгоднее делать локальные выборки, но глобальные изменения. Т.е. подписчик репликации будет работать с локальной копией без доп. издержек, и замечать лаги только при попытках изменения данных.

 

Если данных много, если меняются они реже, чем выбираются (обычно так и происходит), если канал стабильный, но не сверхширокий, то выгоднее делать локальные выборки, но глобальные изменения.

А.. Экономические соображения. Это - да. Но - частный случай. Типовая тенденция-же удешевление каналов и ОДНОВРЕМЕННО повышение их доступности.
И еще: твоя схема распределения данных заточена под конкретный профиль доступа к ним. Т.е. реализовываться она будет на уровне приложения, а не системы. Именно это я имею в виду в еще одной своей "теореме" :
- К любому конкретному СУБД-шному приложению можно прикрутить репликатор (свой!), но как общесистемный сервис репликация в СУБД невозможна
и с другой стороны
- К любому конкретному LND-шному приложению можно прикрутить транзакцию, но на общесистемном уровне она невозможна

 

- К любому конкретному СУБД-шному приложению можно прикрутить репликатор (свой!), но как общесистемный сервис репликация в СУБД невозможна
и с другой стороны
- К любому конкретному LND-шному приложению можно прикрутить транзакцию, но на общесистемном уровне она невозможна

+1 хорошо сказанно.

Только вот что-то однобокое обсуждение LND у нас получается, - только в контексте баз данных, но ведь не меньшее значение имеет втроенный сервер приложений. Фактически изначально LND создавался как сервер приложений, а база данных была добавлена как довесок к нему, как симбиотичный, но инородный елемент. LND - сервер приложений со встроенной базой данных, а не база данных с надстроенным сервером приложений. Все таки если вам нужна большая и полноценная база данных то ИМХО все таки её нужно прикручивать к LND отдельно. А возможностями встроенноя базы данных, специализированной под конкретный сервер приложений, а не под универсальную обработку структурированных данных, пользоваться руководствуясь здравым смыслом и не громоздить вавилоны, а потом жаловаться, что башня "едет".

 

Pasha Чего притих?

На работу добирался.

А.. Экономические соображения. Это - да. Но - частный случай. Типовая тенденция-же удешевление каналов и ОДНОВРЕМЕННО повышение их доступности.
И еще: твоя схема распределения данных заточена под конкретный профиль доступа к ним. Т.е. реализовываться она будет на уровне приложения, а не системы. Именно это я имею в виду в еще одной своей "теореме" :
- К любому конкретному СУБД-шному приложению можно прикрутить репликатор (свой!), но как общесистемный сервис репликация в СУБД невозможна
и с другой стороны
- К любому конкретному LND-шному приложению можно прикрутить транзакцию, но на общесистемном уровне она невозможна

Никакой канал не позволит гонять туда-сюда серьезные объемы данных. Запросы с результатами по пару сотен строк - еще может быть, чуть больше - и заказчики не дадут тебе спокойно спать. Опять же, сетевые задержки пока еще никто не отменял.
СУБД уже давно умеют делать репликацию прозрачно для клиентов. Эта схема распределения данных реализуется на уровне системы, а не приложения. Администратором БД, а не разработчиком. С использованием стандартных репликаторов, а не своих. Т.е. приложение, ничего не подозревая, работает с локальной базой. И только пользователь может заметить небольшие лаги при сохранении изменений. Так что в твоей теореме верна только вторая часть. Соскакивайте с лотуса и переходите на .NET

 

1.Никакой канал не позволит гонять туда-сюда серьезные объемы данных.
2.СУБД уже давно умеют делать репликацию прозрачно для клиентов. Эта схема распределения данных реализуется на уровне системы, а не приложения.

К 1-му: канал - позволит (чем дальше, тем больше). Но кто за него заплатит? Хотя есть тенденция не считать (см. выше байку про IBM)
Ко 2-му: Во 1-х не так давно (репликации журнала транзакций в Оракле еще пяти лет нет, пожалуй); во 2-х - это профанация, а не репликация. Я не зря свои тезисы теоремами обозвал. Они доказываются "от противного", достаточно строго. Публиковал я их кажется у Ника на нотеснет.ру, расписывать еще раз тут - лень.
ЛаНДа! Вот тебе частный случай на затравку: есть в СУБД такая прелестная штучка Sequence - просто воплощенная мощь транзакции. Ну, и как система сама, прозрачно, независимо от юзера и разработчика, растянет её по распределенной среде?

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

Думаю, ты прав. Из LND вышел крутой сервер приложений благодаря "все в одном флаконе".
Но уникальность его IMHO определяется в 1-ю очередь этой базой, с её документо-ориентированностью, non-1st-нормальностью и встроенным репликатором

Клёво по-флеймили

 

К 1-му: канал - позволит (чем дальше, тем больше). Но кто за него заплатит? Хотя есть тенденция не считать (см. выше байку про IBM)

Пока что канал позволяет без проблем реплицировать изменения, но не позволяет пропихивать результаты крупных запросов.

Ко 2-му: Во 1-х не так давно (репликации журнала транзакций в Оракле еще пяти лет нет, пожалуй);
ЛаНДа! Вот тебе частный случай на затравку: есть в СУБД такая прелестная штучка Sequence - просто воплощенная мощь транзакции. Ну, и как система сама, прозрачно, независимо от юзера и разработчика, растянет её по распределенной среде?

Кто вообще говорит про оракл и его проблемы фишки типа Sequence? TR/IU был в 7-ом MS SQL, это восемь-девять лет назад. И Sequence в нем реализуется на обычных таблицах, вполне нормально реплицируется и вполне нормально растягивается. А еще в те же распределенные транзакции можно запихнуть все что угодно, от файлов на диске до вызвов веб-сервисов.

во 2-х - это профанация, а не репликация. Я не зря свои тезисы теоремами обозвал. Они доказываются "от противного", достаточно строго. Публиковал я их кажется у Ника на нотеснет.ру, расписывать еще раз тут - лень.

Ну не расписывай, хотя бы ссылку дай. Доказать лотусистам, которые никогда с нормальными СУБД не работали - это очень просто.
Вот смотри: Репликация есть только в лотусе. Лотус - не РСУБД. Значит в РСУБД транзакций нет.

 

Кто вообще говорит про оракл и его проблемы фишки типа Sequence? TR/IU был в 7-ом MS SQL, это восемь-девять лет назад. И Sequence в нем реализуется на обычных таблицах, вполне нормально реплицируется и вполне нормально растягивается. А еще в те же распределенные транзакции можно запихнуть все что угодно, от файлов на диске до вызвов веб-сервисов.

"Вот вы и попались Штиглиц.."(с)
Распределенная транзакция не подразумевает распределенной среды.

Что по твоему есть распределенная среда?
Два компа, соединенных проводочком (и с общей базой на них), стоящих в одной комнате - распределенная среда?
А если они в соседних комнатах?
А в соседних городах?
А если в одной комнате, но проводочек не 1м, а бухта лежит 10км?
С какой длины проводка или радиоканала начинается распределенная среда?
Бессмыслица?

Вот! Расстояние между частями инф.системы не имеет значения! А что имеет?

Фишка выпала из сетевухи, уборщица порвала проводок, бульдозер переехал кабель, вспышка на солнце испортила радио связь.. -> чистА централизованная инф.система разваливается, а распределенная - должна сохранить работоспособность. Это и есть её признак.

Строго: распределенная инф.система это та, в которой в произвольный момент времени невозможна распределенная двухфазная транзакция

 

"Вот вы и попались Штиглиц.."(с)
Распределенная транзакция не подразумевает распределенной среды.
....

К чему вообще этот мегатекст? На чем это я вдруг так поймался? Я где-то упоминал распределенную среду? И вообще, с чего ты взял что репликация нарушает транзакционность в СУБД? Как ты себе этот процесс представляешь? Берем завершенную локальную транзакцию и откатываем? Ну-ну....
А вот это вообще отжиг:

Строго: распределенная инф.система это та, в которой в произвольный момент времени невозможна распределенная двухфазная транзакция

Распределенная инф.система это та, в которой в произвольный момент времени невозможно завершить распределенную двухфазную транзакцию. Почувствуйте разницу. Из твоего определения можно все что угодно вывести. Например, невозможность репликации в СУБД, или какую-то ее "недоделанность". Распределенные транзакции вполне существуют, и обладают всеми ACID свойствами. Причем организуются они прозрачно для разработчика.

Репликация в СУБД существует, и широко используется. Использование СУБД не подразумевает централизованную систему. Везде давно используется SOA. Лотус занимает мелкую часть рынка, и постепенно вымирает. Смиритесь с фактами и закройте раздел на форуме.

 

К чему вообще этот мегатекст? На чем это я вдруг так поймался? Смиритесь с фактами и закройте раздел на форуме.

Кроме рекламных слоганов чем-то свою т.зр. можешь аргументировать? МЫСЛЬ показать? Не обязательно свою (по возможности)..

Ты тут модер - тебе и смиряться, и раздел закрывать

 

Кроме рекламных слоганов чем-то свою т.зр. можешь аргументировать? МЫСЛЬ показать? Не обязательно свою (по возможности)..

Отлично. Надергал из моего сообщения три фразы, и полностью опустил то, то обсуждали. Т.е. с одновременным существованием репликации и транзакций в РСУБД ты смирился? Теорема оказалась противоерчащей объективной действительности?
При чем тут рекламные слоганы? Ты можешь объяснить что имел в виду своей фразой:

"Вот вы и попались Штиглиц.."(с)

А мысль - очень простая, ее выше высказывал vladoos. РСУБД + SOA = LND по возможностям. А если присмотреться, то РСУБД + SOA >> LND, т.к. поддерживает нормальные распределенные транзакции в распределенной среде, c occasionally connected клиентами, не накладывает странных ограничений на UI, позволяет не привязыватся к конкретному продукту и производителю, интегрируется с существующей инфраструктурой, обладает низким порогом входа, не требует высокой квалификации для поддерки... Достаточно подробно МЫСЛЬ расписал?

 

Отлично. Надергал из моего сообщения три фразы, и полностью опустил то, то обсуждали. Т.е. с одновременным существованием репликации и транзакций в РСУБД ты смирился? Теорема оказалась противоерчащей объективной действительности?
При чем тут рекламные слоганы? Ты можешь объяснить что имел в виду своей фразой:

А мысль - очень простая, ее выше высказывал vladoos. РСУБД + SOA = LND по возможностям. А если присмотреться, то РСУБД + SOA >> LND, т.к. поддерживает нормальные распределенные транзакции в распределенной среде, c occasionally connected клиентами, не накладывает странных ограничений на UI, позволяет не привязыватся к конкретному продукту и производителю, интегрируется с существующей инфраструктурой, обладает низким порогом входа, не требует высокой квалификации для поддерки... Достаточно подробно МЫСЛЬ расписал?

1)вопрос был в аргументации...

поддерживает нормальные распределенные транзакции,использует

используется и работает это разные вещи т е у нас например более 20 филиалов работает на Лотусе,тут вам приведут кучу примеров использования Лотус и репликации где филиалы в разных странах мира и я такие знаю...приведите примеры и Вы...c нормальной работой...
2)я здесь писал о проблемах и охах пользователей VB и полуавтоматическом переводе приложений с VB на VB.NET unreal даже нарушили порядок индексации масивов Все надо с нуля переписывать
а теперь сравните переход например с 5 ой версии на 6 ю Лотус,все вполне в совместимо,и возможно заменить новые функции 6 ки на те что исп в 5 ке и запускать лотус приложения на 6 ке под 5 ку
3)читайте

Вот вам ещё один закон Эллисона (на сей раз не Ларри, а Харлан):

Миф репликации

Многие верят, что имея перегруженный сервер, они могут поставить рядом второй такой же, настроить двустороннюю репликацию и снизить нагрузку на существующий сервер вдвое. В конечно итоге, ведь 1+1=2, поэтому, добавляя в два раза больше железа мы сможем работать в два раза быстрее, верно? Ответом будет только "может быть".

Что необходимо сделать одному серверу, чтобы выполнить транзакцию?
Выполнить транзакцию.
Что необходимо сделать находящемуся в репликации серверу?
Выполнить транзакцию.
Поместить транзакцию в очередь на репликацию.
Организовать передачу на другие узлы.
После успешного применения транзакции, удалить её из очереди.
Нюансы могут зависеть от того, используете вы pull- или push-репликацию, а так же от конкретной технологии. Но бесплатного ланча не будет - любая технология репликации требует дополнительных ресурсов для организации корректной передачи и применения транзакций. В нашем примере, серверу необходимо выполнить четыре шага вместо одного. Помимо выполнения своих транзакций, бедняге необходимо ещё принимать и выполнять транзакции соседа. Теперь вам необходимо иметь дело с распределёнными транзакциями.

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

Гималайская мечта

И так, вы думаете что масштабирование системы заключается в бесконечном добавлении Гималайских серверов приложений?

Добро пожаловать в реальный мир

Как только вы организуете вынесенный из СУБД кэш - вы, по-сути, собираетесь делать репликацию. Изменяющиеся данные в СУБД необходимо синхронизировать с внешним кэшем. Если вы допускаете изменение данных в кэше приложения - изменения необходимо синхронизировать обратно в СУБД. Вот и готова двусторонняя репликация. Чем больше узлов вы добавляете - тем больше становится нагрузка на каждый из узлов в отдельности.

Вам необходимо ещё больше железа, чтобы делать ту же самую работу ещё медленней.

Кто-то прогулял начальную школу

Если количество изменений данных в СУБД превышает количество запросов этих данных с серверов приложений - затраты на синхронизацию будут несоизмеримо выше, чем запрос тех же данных напрямую из СУБД.

Один такой "High Speed" сервер приложений, использующий "новейшую технологию кэширования, кардинально увеличивающую производительность и масштабируемость" (попробуйте погуглить это) за одну синхронизацию кэша потр*цензура*л ресурсы, достаточные для недельной работы системы, если бы никакого кэша не было вообще и все запросы шли напрямую к СУБД Oracle. А синхронизацию он выполнял каждые двадцать минут. Упс... Похоже, кто-то просто не умел считать.

Но ведь 1+1=2

И это правда. Только в данном случае - это оказалась результирующая нагрузка на каждый компонент системы.

Необходимость что-то делать приходит довольно быстро. Как только вы осознаете, что самый большой сервер для СУБД в мире не способен вас спасти. Одного этого должно быть достаточно, чтобы начать приходить к мысли "что-то было сделано чертовски неправильно".

Но что? Ах... вот тут у нас проблема! Всем известно, что Oracle плохо сортирует данные, поэтому все пишут сортировку на клиентах методом пузырька. А ещё Oracle плохо джойнит таблицы. И все знают, что проблема PL/SQL заключается в том, что это интерпретируемый язык - он никогда не будет работать быстро. Ребята из Redwood Shores просто слишком много смотрели телевизор.

Вот и ответ - архитектура СУБД Oracle не даёт нам масштабироваться. Трасса для формулы 1 не подходит для езды по ней на лыжах? Заберите нас в Гималаи - нас спасут сервера приложений.

 

Ну так пусть приведут.
Вы путаете мягкое с пушыстым. Это не просто смена версии и все что с этим связано, это совершенно разные технологии и подходы.
Сама приставка .NET уже дает много почвы для размышления, ведь не по прихоти ее туда прилипили. И если бы эти пользователи подумали немного, равно как и почитали, то охав и ахов было бы меньше.
Далее думаю сами поймете всю несостоятельность ваших сопоставлений с изменениями версий лотуса?
И мое мнение по поводу смены версий, - приемственность и поддержка пред. версий не есть чистый гуд. С одной стороны, да, все красиво все шоколадно, но с другой мы имеем некоторые тормоза в развитии. Что перевешивает решает каждый для себя.

А откуда взято все остальное?

1)Ну могу и я примеры привести...в Киеве количество банков переходящих на Лотус документооборот(офис+все филиалы+репликация(почта+приложения)) все больше и больше, а спецы все востребованей и востребованей...в стороу Microsoft и Exchange Server никто и не смотрит

теперь примеры разрепликаций от Oracle

2)В этом и плюс Лотуса совестимость приложений несмотря на версию...
Переход на другую платформу и значит надо по другому организовывать нумерацию в масивахдействительно ведь другая платформа

В VB .NET имена массивов должны подчиняться тем же правилам, что и имена переменных. Ссылка на элемент массива выглядит как имя массива, за которым в круглых скобках указывается индекс.

Массивы VB .NET во многом отличаются от массивов VB6. Одни изменения видны сразу, другие не столь очевидны. Наиболее заметные изменения перечислены ниже.
Индексация-элементов в массивах начинается с 0. На момент написания книги ключевое слово То не поддерживалось — будем надеяться, что оно еще вернется!

Начиная с бета-версии 2 объявление 01m stri ngLi st(7) создает массив из восьми элементов с индексами от 0 до 7. Поскольку в VB .NET индексация всегда начинается с нуля, третий элемент массива обозначается stri ngList(2), а предшествующие элементы обозначаются stringList(0) и stringList(l).
Все массивы VB .NET являются динамическими. Во время работы программы их можно переобъявить с новым размером при помощи команд ReDim (с потерей текущего содержимого) и ReDim Preserve (с сохранением текущего содержимого).

3)Yandex+Google-найдется все...