А причем здесь это!Цитата:
Сообщение от RZ4AG
Мой старый лог работает в тестах и я это могу утверждать ...
А насчет идеолога так я туда и не лезу ... Вот так
Вид для печати
А причем здесь это!Цитата:
Сообщение от RZ4AG
Мой старый лог работает в тестах и я это могу утверждать ...
А насчет идеолога так я туда и не лезу ... Вот так
Игорь, я и не собирался утверждать что ваш лог не умел раньше этого делать. И это ваш право сливать все в "один флакон". Я имел ввиду что новая реинкарнация :) вашего лога вовсе не то, что планировалось при начале обсуждения того топика.Цитата:
Сообщение от UR5FCM
Добавлено через 30 минут
Это частный случай. ICOM, Kenwood и Yaesu используют разный формат, в который в любом случае преобразовывать.Цитата:
Сообщение от RX1AL
И потом, представленная вами функция не способно серьезно повлиять даже на Pentium-266, не говоря уж о современных компьютерах.
Кенвуд частоту вообще в текстовом формате передает.Цитата:
Сообщение от RZ4AG
А у есу частота у некоторых аппаратов вообще не поймешь как передается. У некоторых - до десятков герц округляется, у некоторых bcd.
imho разумньім решением здесь будет не городить свой прямой доступ из лога к трансиверу, а воспользоваться уже разработанной библиотекой.Цитата:
Сообщение от RX4HX
Библиотека hamlib имеет все необходимое (см. прим. в моих пред. постах).
Только как бьіть, если тут предлагают лог для линукса писать под ... виндой :-) ?
Хотя с hamlib и здесь проблем, 96 из 100, бьіть не должно (все уже портировано до нас).
Под какой виндой предлагают писать??? Коллега, вы бы отдохнули и в период отдыхаЦитата:
Сообщение от UR3LCM
познакомились бы чуть-чуть с системой Mono. Линки для вас ниже, если интересно:
1. http://monodevelop.com/ - Среда разработки MonoDevelop для линукс
2. http://www.mono-project.com/Main_Page - все по проекту Mono.
И где вы здесь видите слово "виндоус"? Скажите...
Что касается библиотеки hamlib, то и с ней не 96%, а максимум на 75% только стабильности.
Проблем с трансиверами и их управлением навалом - почитайте рефлекторы.
Реплика на мое рассуждение о связях в применяемьіх нами БД.Цитата:
Сообщение от RX1AL
Да! MySQL 5 предоставляет доступ к своим внутренним параметрам/данньім посредством специальной БД information_schema (правило доктора Кодда о представлении информации и о динамических каталогах в реляц.БД). Єту системную БД можно использовать в т.ч. и в приложениях, что расширяет наши возможности. Но рассмотрим пример:
Пусть БД имеется две таблицьі: qsolog и qrzfile связанньіе по полям callsign. Создаем БД и загружаем данньіе из неких файлов:
CREATE DATABASE hamlog DEFAULT CHARACTER SET utf8; USE hamlog;
CREATE TABLE qsolog (callsign, ля-ля-ля); CREATE TABLE qrzinf (callsign, жу-жу-жу);
INSERT DATA INFILE qsofile INTO TABLE qsolog; INSERT DATA INFILE qrzfile INTO TABLE qrzinf; СТОП! В данньій момент БД создана? - imho уже создана.
Вопрос: Связи между полями таблиц инициированьі/описаньі/представленьі? (запросами категории DDL - Data Definition Language и DML - Data Manipulation Language)
Ответ: Нет! Связи пока только у нас в голове.
Вопрос: Связи хранятся непосредственно в БД, или определяются как-то отдельно?
Ответ: Связи определяются в предикатах (последующих) запросов (в запросах категории DQL - Data Query Language).
Извините коллега! Я не хотел Вас обидить.Цитата:
Сообщение от RX1AL
Претензий к "западной образованности" у меня нет и опьіт работьі в извесньіх компаниях ценю (сам имел дело с Siemens AG). Все хорошо, особенно если в меру. Просто у тех, кто получил вьісшее образование и опьіт работьі за "железной завесой" абревиатура SQL ассоциируется с произношением "єс-ку-єл". Как например и QNX - "ку-єн-єкс", а не "кУникс". Но все меняется. Ньінче я тоже произношу - "сик-вєлл" (хорошо искать), но абревиатуру SQL распространяю намного дальше продуктов от Oracle (утверждение о их вьісочайшем уровне поддерживаю).
Коллега, молодой человек, юноша, студент...Цитата:
Сообщение от UR3LCM
Вы написали "но рассмотрим пример:" [..такой рассмотрeл весь пример под лупой..]
и обнаружил, что студент плохо знаком с материалами по языку DDL. А именно в части
ключевого слова CONSTRAINTS: {CONSTRAINT} [constraint definition], которое служит
для декларации и создания связей между таблицами в базе данных, т.е. то, что называют
по-другому Data Relationships. Кроме того, как уже писалось, DDL служит и для декларации
Referential Integrity между Primary Key и Foreign Key. Поэтому на ваш вопрос и ваш же ответ
"связи пока только у нас в голове" - ответ будет строго отрицательным. Это у вас они в голове,
а нормальные люди (грамотные разработчики) все определяют в DDL. Так как знают, что
DQL (по-другому Structured Query Language или SQL), DML и даже DCL не позволит им
впоследствии это сделать, как и назначить индекс IX в поле/полях таблицы/таблиц. Для вас
специально ниже цитата из документации по DQL и DML:
"To retrieve, INSERT, DELETE and modify data in the RDBMS, use the Data Manipulation Language (DML)
and Data Query Language (DQL). DML and DQL allows an application to do the following:
* SELECT: Retrieve rows of data.
* INSERT: Place new rows of data in the database.
* UPDATE: Replace existing values in the database with new values.
* DELETE: Delete rows of data in the database."
То есть то, что называют все разработчики CRUD Pattern (Create, Retrieve, Update, Delete).
И где здесь ваши пресловутые связи между таблицами? Поэтому [..такой ставит два..] - идите поучите.
По поводу написания программы в виндах для линукса или в линуксе, используя Mono, у вас похоже
нет аргументов ... судя по всему.
Насчет, как правильно произносить аббревиатуры SQL, QSO, QTH я знаю. И по-английски и по-немецки.
В последнем будет: "Эс-Ку-Эль", "Ку-Эс-О" и "Ку-Тэ-Ха", с немецким "ха" в конце.
То, что многие используют жаргонное "сиквел" или другие слова в программерстве, давно норма.
И ваше "Ку-Эн-Экс" не правильно, та как "Кью..." первая, а не "два раза ку". :)
PS Не надо пытаться искать ошибки, я все же преподаю информатику в универе на западе не первый год.
Параллельно работаю в министерстве по газу и нефти.
Поскольку по топику постов нет, то позволю себе еще немного порассуждать вокруг да около Linux HAM-log.
Ага(с украинско-немецким "га")! Понятно.. єто Вьі примерно об єтом:Цитата:
Сообщение от RX1AL
CREATE TABLE qrzinf (жу-жу-жу, callsign.., PRIMARY KEY (callsign)) ENGINE=InnoDB;
CREATE TABLE qsolog (ля-ля-ля, callsign.., FOREIGN KEY (callsign)
REFERENCES qrxinf(callsign)
ON UPDATE CASCADE ON DELETE CASCADE ..) ENGINE=InnoDB;
Однако:
1) В MySQL сие поддерживается только для таблиц InnoDB :-(( (согласен, что das ist софсемпльохо);
2) Рассматриваемая СУБД ПОЗВОЛЯЕТ, но НЕ ОБЯЗЬІВАЕТ описьівать связи между таблицами в DDL запросах;
3) Без єтого можно обойтись, а БД будет оставаться реляционной.
Вьівод: явное описание связей (в DDL части) улучшает ТТХ системьі, но не является обязательньім для т.н. реляционной БД
(или БД из пред.поста не может считаться реляционной).
imho DDL можно применять и впоследствии. Напр. ALTER TABLE.Цитата:
Сообщение от RX1AL
Сугубо мое личное мнение (стараюсь держать при себе, но если настаиваете..):Цитата:
Сообщение от RX1AL
Багаж приобретенньій в винде, при переходе на юникс платформьі, єто как крокодиловьій чемодан без ручки, или лучше сказать - чемодан с колесиками на пляже. Дальше Вьі знаете: и нести тяжело, и бросить жалко. Вот и понапридумьівали различную упряжь(МОNO).. в надежде, что еще послужит. Многим нравится.. Особенно внешне ;)
SCSI - єс-си-єс-ай, или всеже "скАзи"? Вторая буква = "ка"|"си"|"се"|"Ваш вариант"?
Коллега, [..такой прочитал все до конца..] вам надо учить матчасть, искренне советую.Цитата:
Сообщение от UR3LCM
Каша в голове, очень большая каша. И еs ist schlecht (без всяких das) или Ganz, Ganz schlecht!
Тепрь разберем ваше "примерно об этом". Не примерно, а точно об этом. Поскольку все связи
между таблицами назначаются сразу, а не потом, когда рак свистнет или петух клюнет. Это
нормальный стиль и норма, если хотите. Создание таблиц без явных связей, т.е. Flat таблиц
настолько ужасный стиль, что в любой нормальной фирме за него просто увольняют сразу.
Далее... Мы не зациклились на MySQL? Есть и другие базы данных... где все нормально реализовано.
Или такая любовь к MySQL из-за явной простоты? По поводу ALTER TABLE - опять мимо кассы.
Вы иногда читаете документацию, очень хотел спросить? Потому, что ALTER TABLE предназначена
для:
"The ALTER TABLE statement allows you to rename an existing table. It can also be used to add, modify,
or drop a column from an existing table."
Синтаксис ее (полный) ниже:
ALTER TABLE [ database_name . [ schema_name ] . | schema_name . ] table_name
{
ALTER COLUMN column_name
{
[ type_schema_name. ] type_name [ ( { precision [ , scale ]
| max | xml_schema_collection } ) ]
[ COLLATE collation_name ]
[ NULL | NOT NULL ] [ SPARSE ]
| {ADD | DROP }
{ ROWGUIDCOL | PERSISTED | NOT FOR REPLICATION | SPARSE }
}
| [ WITH { CHECK | NOCHECK } ]
| ADD
{
<column_definition>
| <computed_column_definition>
| <table_constraint>
| <column_set_definition>
} [ ,...n ]
| DROP
{
[ CONSTRAINT ] constraint_name
[ WITH ( <drop_clustered_constraint_option> [ ,...n ] ) ]
| COLUMN column_name
} [ ,...n ]
| [ WITH { CHECK | NOCHECK } ] { CHECK | NOCHECK } CONSTRAINT
{ ALL | constraint_name [ ,...n ] }
| { ENABLE | DISABLE } TRIGGER
{ ALL | trigger_name [ ,...n ] }
| { ENABLE | DISABLE } CHANGE_TRACKING
[ WITH ( TRACK_COLUMNS_UPDATED = { ON | OFF } ) ]
| SWITCH [ PARTITION source_partition_number_expression ]
TO target_table
[ PARTITION target_partition_number_expression ]
| SET ( FILESTREAM_ON = { partition_scheme_name | filegroup |
"default" | "NULL" } )
| REBUILD
[ [PARTITION = ALL]
[ WITH ( <rebuild_option> [ ,...n ] ) ]
| [ PARTITION = partition_number
[ WITH ( <single_partition_rebuild_option> [ ,...n ] ) ]
]
]
| (<table_option>)
}
[ ; ]
Если вы покажете, где есть здесь слова: CREATE, CONSTRAINTS и INDEX - будет очень здорово.
Насчет багажа и крокодилового чемодана без ручки. Вам не кажется, что знание языка C, C++,
Java не зависят от выбора платформы? А учитывая опыт работы и написания программ под
линукс в течение минимум лет 20 - думаю, он приличный... :) Относительно Mono (.NET). А чем
собственно отличается среда? Тем, что в ней появился язык C# и еще куча других языков? Так
что ли? Похоже, рассуждать о вкусе устриц вы не можетe, так как их не пробовали. Простите, но
когда пишут "многим нравится, только внешне" - это значит, не написать самому ни одного
приложения под линукс на этой платформе. Добавлю, что кроме нее есть и Qt. Qt тоже поддерживает
работу с Mono (.NET). Так что ваши аргументы ... мягко скажем, не убедительны.
Также важно, что язык программирования должен поддерживать ОО программирование,
т.е. классы/наследование и т.д.
PS Если у меня будет на следующей неделе время, то выложу в топике уже примерное ТЗ на такой лог
под линукс - без выбора средств разработки - Proof of Concept.
Очень интересно :)Цитата:
Сообщение от RX1AL
Ну вот, чем обычно и кончаются темы........... Рассуждениями у кого яйца больше...... а жаль!!! Хороший лог под линух Было б гораздо полезнее чем знать что твои или его яйца больше!!!:sorry::sorry::sorry:
Вьібрал: Menu -> ... -> Find in This Page.. Долго искал. Слов: CREATE, CONSTRAINTS и INDEX не обнаружил. Включил воображение. Получилось следующее: Создадим БД, см. пост #81Цитата:
Сообщение от RX1AL
CREATE TABLE qrzinf (callsign..,..)..; CREATE TABLE qsolog (callsign..,..)..;
INSERT DATA INFILE .. ; INSERT DATA INFILE .. ;
ГОТОВО! Получена БД, но без явного описания связей.
Поработаем с ней: дрр-дрр-дрр..
Теперь, т.е. ВПОСЛЕДСТВИИ, преобразуем к виду из поста #83
ALTER TABLE qrzinf ENGINE=InnoDb; ALTER TABLE qsolog ENGINE=InnoDb;
ALTER TABLE qrxinf ADD PRIMARY KEY (callsign);
ALTER TABLE qsolog ADD FOREIGN KEY (callsign) REFERENCES qrzinf(callsign) ON DELETE CASCADE ON UPDATE CASCADE;
ГОТОВО! Получена БД уже с явньім описанием связей.
Сам себе не поверил. Возжелал убедиться на практике. Набрал скрипт.
Запустил. Все РАБОТАЕТ!
Во' как иногда оказьівается полезно отрьівать глаза от Reference Manual.
Вспомнилось из Жака Превера: A chaque kilometre chaque annee des vieillards ..
Родился перевод:
На каждом километре
каждом перекрестке куда не пойди
остолбенельіе дорожньіе мєтрьі
жестом железобетонньім детям сулят пути
Мой свободньій перевод с французкого, (С)2010 UR3LCM, Позволяю пользоваться им на условиях лицензии GNU GPL2, если со стороньі Превера возражений не последует :)
Мдяаа... Программист из вас просто замечательный... Нет, чтобы в самомЦитата:
Сообщение от UR3LCM
начале грамотно базу создать - нет, надо сделать все через ж... с кучей
изврата. Левой рукой правое ухо чесать, наверное, легче.
PS Ах да, забыл... Если в вашей базе будет PRIMARY KEY (callsign), то повторный
ввод того же callsign, что сделает? База скажет "Ку-ку, Гриня!" :)
А почему позывной попал в уникальный ключЦитата:
Сообщение от UR3LCM
Будут проблемы с повторными позывными даже если диапазон будет разный
База просто выбросит исключение или ошибку типа индекс уникальный и т.д.
Надоть
[id] [int] как индекс использовать уникальный ...
В данном примере (#87) речь идет не об описании структурьі ham-log БД. Он демонстрационньій и на практике опровергает утверждение Михаила RX1AL (#82):Цитата:
Сообщение от UR5FCM
".. все определяют в DDL. Так как знают, что DQL .., DML и даже DCL не позволит им впоследствии это сделать, как и назначить индекс IX в поле/полях таблицы/таблиц.",
а также его утверждение (#84) о том, что запрос ALTER TABLE НЕ ПОЗВОЛЯЕТ преобразовать БД к нужному виду:
"По поводу ALTER TABLE - опять мимо кассы.. Потому, что ALTER TABLE предназначена для:..".
Данньій пример показьівает, что СУБД MySQL позволяет в любой момент гибко модифицировать БД без потери данньіх в ней. Для разработки ham-log єто имеет важное значение, т.к. позволяет пользователям использовать БД до завершения ее проектирования, а разработчики при єтом не ограничиваются в возможностях дальнейшего развития системьі.
Я показал, что в СУБД MySQL возможно вначале создать таблицьі без определения первичного и внешнего ключей, и естественно без определения связи между ключами. Далее заполнить таблицу данньіми и уже затем добавлять ключи, определить связь и обеспечить т.н. ссьілочную целосность. Внесенньіе ранее данньіе при таких операциях будут сохраненьі.
PRIMARY KEY imho здесь применяется ПРАВИЛЬНО, поскольку я предположил, что таблица qrzinf будет хранить неизменяемую информацию о каждой станции. Напр. дату рождения оператора, дату получения первой лицензии итп. Смотри напр. http://www.qrz.com/db/ или данньій web-ресурс. Для каждого позьівного таблица qrzinf содержит только одну запись. callsign в данном случае является естественньім уникальньім ключем. Название таблицьі произошло от URL сайтов. Может неудачно, я не настаиваю.
Если по некоторой причине отказаться от уникальности поля callsign, то пример можно модифицировать, изменив строки:
ALTER TABLE qrzinf ADD INDEX (callsign);
ALTER TABLE qsolog ADD FOREIGN KEY (callsign) REFERENCES qrzinf(callsign) ON DELETE CASCADE ON UPDATE CASCADE;
Мною на практике проверено, что и в данном случае дальнейшая модификация БД вьіполняется без проблем.