Log под Ubuntu

[UR5FCM]

Была попытка что-то сделать для ТЕСТОВ вполне конкретными людьми. И Игорь там был далеко не главным идеологом.

А причем здесь это!
Мой старый лог работает в тестах и я это могу утверждать ...
А насчет идеолога так я туда и не лезу ... Вот так

[RZ4AG]

Мой старый лог работает в тестах и я это могу утверждать ...
А насчет идеолога так я туда и не лезу ... Вот так

Игорь, я и не собирался утверждать что ваш лог не умел раньше этого делать. И это ваш право сливать все в "один флакон". Я имел ввиду что новая реинкарнация вашего лога вовсе не то, что планировалось при начале обсуждения того топика.

Добавлено через 30 минут

о поводу хранения все же частоты в int, не будет удобно, IMHO. Интерфейс САТ воспринимает
частоту, как последовательность байт (в формате BCD с обратной последовательностью).

Это частный случай. ICOM, Kenwood и Yaesu используют разный формат, в который в любом случае преобразовывать.
И потом, представленная вами функция не способно серьезно повлиять даже на Pentium-266, не говоря уж о современных компьютерах.

[RX4HX]

Kenwood

Кенвуд частоту вообще в текстовом формате передает.
А у есу частота у некоторых аппаратов вообще не поймешь как передается. У некоторых - до десятков герц округляется, у некоторых bcd.

[UR3LCM]

Кенвуд частоту вообще в текстовом формате передает.
А у есу частота у некоторых аппаратов вообще не поймешь как передается. У некоторых - до десятков герц округляется, у некоторых bcd.

imho разумньім решением здесь будет не городить свой прямой доступ из лога к трансиверу, а воспользоваться уже разработанной библиотекой.
Библиотека hamlib имеет все необходимое (см. прим. в моих пред. постах).
Только как бьіть, если тут предлагают лог для линукса писать под ... виндой :-) ?
Хотя с hamlib и здесь проблем, 96 из 100, бьіть не должно (все уже портировано до нас).

[RX1AL]

Библиотека hamlib имеет все необходимое (см. прим. в моих пред. постах).
Только как бьіть, если тут предлагают лог для линукса писать под ... виндой?

Под какой виндой предлагают писать??? Коллега, вы бы отдохнули и в период отдыха
познакомились бы чуть-чуть с системой Mono. Линки для вас ниже, если интересно:
1. http://monodevelop.com/ - Среда разработки MonoDevelop для линукс
2. http://www.mono-project.com/Main_Page - все по проекту Mono.
И где вы здесь видите слово "виндоус"? Скажите...

Что касается библиотеки hamlib, то и с ней не 96%, а максимум на 75% только стабильности.
Проблем с трансиверами и их управлением навалом - почитайте рефлекторы.

[UR3LCM]

7. Без разницы с какой базой мы работаем... У той же MySQL 5 есть INFORMATION_SCHEMA... Или вы
мне опять докажете, что это не так?

Реплика на мое рассуждение о связях в применяемьіх нами БД.
Да! 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).

PS По поводу "западной образованности". Вы что-то имеете против такой образованности? Я например, ничуть не против, а даже за.

Извините коллега! Я не хотел Вас обидить.
Претензий к "западной образованности" у меня нет и опьіт работьі в извесньіх компаниях ценю (сам имел дело с Siemens AG). Все хорошо, особенно если в меру. Просто у тех, кто получил вьісшее образование и опьіт работьі за "железной завесой" абревиатура SQL ассоциируется с произношением "єс-ку-єл". Как например и QNX - "ку-єн-єкс", а не "кУникс". Но все меняется. Ньінче я тоже произношу - "сик-вєлл" (хорошо искать), но абревиатуру SQL распространяю намного дальше продуктов от Oracle (утверждение о их вьісочайшем уровне поддерживаю).

[RX1AL]

Реплика на мое рассуждение о связях в применяемьіх нами БД.

Коллега, молодой человек, юноша, студент...
Вы написали "но рассмотрим пример:" [..такой рассмотр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 Не надо пытаться искать ошибки, я все же преподаю информатику в универе на западе не первый год.
Параллельно работаю в министерстве по газу и нефти.

[UR3LCM]

Поскольку по топику постов нет, то позволю себе еще немного порассуждать вокруг да около Linux HAM-log.

... в части ключевого слова CONSTRAINTS: {CONSTRAINT} [constraint definition], которое служит для декларации и создания связей между таблицами в базе данных, ... по-другому Data Relationships.

Ага(с украинско-немецким "га")! Понятно.. єто Вьі примерно об єтом:
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 части) улучшает ТТХ системьі, но не является обязательньім для т.н. реляционной БД
(или БД из пред.поста не может считаться реляционной).

... нормальные люди (грамотные разработчики) все определяют в DDL... знают, что DQL (по-другому Structured Query Language или SQL), DML и даже DCL не позволит им впоследствии это сделать, как и назначить индекс IX в поле/полях таблицы/таблиц.

imho DDL можно применять и впоследствии. Напр. ALTER TABLE.

По поводу написания программы в виндах для линукса или в линуксе, используя Mono, у вас похоже нет аргументов ... судя по всему.

Сугубо мое личное мнение (стараюсь держать при себе, но если настаиваете..):
Багаж приобретенньій в винде, при переходе на юникс платформьі, єто как крокодиловьій чемодан без ручки, или лучше сказать - чемодан с колесиками на пляже. Дальше Вьі знаете: и нести тяжело, и бросить жалко. Вот и понапридумьівали различную упряжь(МОNO).. в надежде, что еще послужит. Многим нравится.. Особенно внешне

SCSI - єс-си-єс-ай, или всеже "скАзи"? Вторая буква = "ка"|"си"|"се"|"Ваш вариант"?

[RX1AL]

Поскольку по топику постов нет, то позволю себе еще немного порассуждать
....
Вот и понапридумьівали различную упряжь(МОNO).. в надежде, что еще послужит. Многим нравится.

Коллега, [..такой прочитал все до конца..] вам надо учить матчасть, искренне советую.
Каша в голове, очень большая каша. И е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.

[RZ3DUA]

PS Если у меня будет на следующей неделе время, то выложу в топике уже примерное ТЗ на такой лог
под линукс - без выбора средств разработки - Proof of Concept.

Очень интересно

[R3DMO]

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

[UR3LCM]

По поводу 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 . ]
... [ ; ]
Если вы покажете, где есть здесь слова: CREATE, CONSTRAINTS и INDEX - будет очень здорово.

Вьібрал: Menu -> ... -> Find in This Page.. Долго искал. Слов: CREATE, CONSTRAINTS и INDEX не обнаружил. Включил воображение. Получилось следующее: Создадим БД, см. пост #81
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, если со стороньі Превера возражений не последует

[RX1AL]

ГОТОВО! Получена БД, но без явного описания связей.
ГОТОВО! Получена БД уже с явньім описанием связей.

Мдяаа... Программист из вас просто замечательный... Нет, чтобы в самом
начале грамотно базу создать - нет, надо сделать все через ж... с кучей
изврата. Левой рукой правое ухо чесать, наверное, легче.

PS Ах да, забыл... Если в вашей базе будет PRIMARY KEY (callsign), то повторный
ввод того же callsign, что сделает? База скажет "Ку-ку, Гриня!"

[UR5FCM]

ALTER TABLE qrxinf ADD PRIMARY KEY (callsign);

А почему позывной попал в уникальный ключ
Будут проблемы с повторными позывными даже если диапазон будет разный
База просто выбросит исключение или ошибку типа индекс уникальный и т.д.
Надоть
[id] [int] как индекс использовать уникальный ...

[UR3LCM]

А почему позывной попал в уникальный ключ
Будут проблемы с повторными позывными даже если диапазон будет разный ..

В данном примере (#87) речь идет не об описании структурьі ham-log БД. Он демонстрационньій и на практике опровергает утверждение Михаила RX1AL (#82):
".. все определяют в 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;
Мною на практике проверено, что и в данном случае дальнейшая модификация БД вьіполняется без проблем.