Drovosek01

Вот такой запрос работает.

CREATE TABLE IF NOT EXISTS `tbl` (
  `id` INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL ,
  `name` varchar(255) NOT NULL);

Небольшой рецепт на будущее для решения подобных проблем: создаете визардом таблицу нужного вида и смотрите на скрипт создания.

Помогли наконец разобраться. Path - это переменная, и в неё надо прописывать пути, т. е. каталоги, в которых будут искаться исполняемые файлы.
Надо было зайти в переменные среды и добавить в переменную Path через точку с запятой: C:\Program Files\MySQL\MySQL Server 5.6\bin\

Нужно создать новую модель, в меню выбрать Database -> Reverse Engineer. Дальше там более-менее понятно.

P.S. Ужасная, глючная неинтуитивная программа... По крайней мере под Линуксом.

.iso файлы - это неформальный термин для обозначение образа оптического диска, который изначально позволял полноценно хранить файловую систему ISO9660, также извествную как CDFS (Compact Disc File System) в виде файла.
В общем смысле позволяет хранить не только ISO9660, но и другой формат оптических дисков: UDF (ISO/IEC 13346), а такжке расширения формата ISO9660: Joilet, Rock Ridge, El Torito, Apple ISO9660 Extension.

Саж же стандарт ISO9660 был принят в 1988 году и описывает универсальную файловую систему для хранения информации на цифровых носителях для совместимости между популярными операционными системами (Unix, Mac OS, Windows и др.), а также огромным количеством электронных устройств, которые могут считывать информацию с цифровых носителей (видео-, аудио- проигрыватели, игровые приставки, CD-плееры, ...).

Кроме самих данных и способа кодирования, на диске могла быть помещена информация о издателе, идентификаторе тома (диска), а тажке дата создания и дата окончания срока службы диска.
Отдельно выделялась область для создания загрузочного сектора (загрузчик установщиков ОС и др.).

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

Создание же полноценной копии с одного носителя на другой носитель "на лету" подходила не для всех (так как требовалось иметь 2 устройства, одно из которых позволяло записывать информацию, а другое использовалось для чтения), а также часть программ для записи дисков на тот момент не поддерживало (технически или юридечески) создание копии 1 к 1, то со временем появилось програмное обеспечение, задача которого была в возможность снять "зеркальную" копию диска и записать в виде специального файла (так, чтобы не была утеряна вся служебная информация) на локальный компьютер.
Таким образом появились самые первые форматы образов дисков (.iso, .img), либо же проприетарные .mdf (Alcohol 120%), .nrg (Nero), .uif (MagicISO), которые в самом начале своего появления решали проблему с копирование служебной информации и использовались как буферный формат при клонированни дисков с использованием 1 записывающего устройства.
Но даже в таком виде диски все равно были более распостранены по сравнению с .iso файлами, так как были основным способом передачи информации в местах, где интернет был еще не доступен. (Хотя и были люди, которые использовал жесткие диски в качестве альтернативого способа передачи данных).
Сами же .iso файлы первоначально не были настолько полезны, так как еще не было эмуляторов CD/DVD дисков, которые были бы интегрированы в файловую систему или же они стоили денег и имели свои собственные проприоретарные форматы, а поддержка ISO9660 была реализована частично или же не поддерживала всех возможностей формата.
Только с увеличением объема жестких дисков и скорости работы в Интернете, а также появлением полноценных эмуляторов .iso файлов, наступило время, когда люди начали отказывать от цифровых дисков и хранить информацию на других носителях.
Но так как разная информация, хранимая на тот момент на цифровых носителях, требовала либо трудозатрат по преобразованию (CD-Audio, DVD-Auido, видеодиски) или же эмуляцию присутствия лицензионного диска в дисководе (игры, специализированный софт),
то большинство людей стало дублировать информацию с цифровых носителей в *.iso файлы, так как это было самым простым решением их проблем.

Поэтому в момент появления *.iso файлы позволили решить актуальные на тот момент задачи (буферный файл, эмуляция специализированных дисков).
Сейчас же *.iso файлы в осном использовазуются только в тех случаях, когда другие способы не могут полноценно помочь в решении поставленной задачи.
Как альтернатива оптическим дискам к тому моменту пришли интернет и флеш-память.
На замену же ISO9660 в 1995 году появилась файловая система UDF, которая смогла решить такие проблемы ISO9660, как возможно записи файлов более 4ГБ, а также перезаписи данных на цифровом носителе (и др.).

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

ISZ - (он же ISO Zipped) уже специализированный формат, который представлеят собой сжатый ISO9660 при помощи zlib или bzip2. Его в основном использовали энтузиасты, чтобы сэкономить часть дискового простатранства там где не предполагалось частое использование *.iso и при этом они были готовы к неудобствам при работе с этим форматом в дальнейшем (время на распаковку, наличие специальных программ).

DMG - это платформо-зависисый формат для хранения образов диска для операционной системы Mac OS.
Кроме тех особенностей, которые давал ISO 9660 в нем также были возможность шифрования информация использование сжатия, а также были реазизованы возможности хранения специфичных для Mac OS метаданных о файлах.
Сейчас данный формат в основном используется как средство распостранения архивов програмного обеспечения при помощи интернета.
К тому же данный формат является "гибдирным" и поддерживает возможность хранения нескольких файловых систем (в том числе и ISO9660) в рамках одного *.dmg файла.

Вероятно эта утилита неправильно интерпретирует данные SMART. Очевидно цифры это мегабайты, а не гигабайты.
200террабайт за два месяца ваш компьютер физически не сможет записать.
Попробуйте CrystalDiskInfo

Основной посыл использования RESTful API - применение основной идеи Паутины для взаимодействия автоматических агентов (приложений), а не только людей.
Основная идея Паутины - построение распределенной информационной системы путем публикации неких абстрактных ресурсов, выдачи им идентификаторов (в сегодняшнем вебе - иерархических), определения ряда простых и широко известных операций над ними, не зависящих от содержимого ресурса (те самые GET, POST, PUT и т.д.), и связывания этих ресурсов ссылками (это называется гипермедиа, и в частности, гипертекст, если речь идет о текстовой информации).
Как люди с появления Веба публикуют информацию в нем для потребления другими людьми, так и RESTful веб-сервисы публикуют иерархически структурированные ресурсы для потребления клиентами. Разница только в представлении - для людей это plaintext/HTML, для автоматических агентов - это JSON/XML/прочие форматы, которые удобно обрабатывать.
Таким образом, если вы хотите какую-то информацию опубликовать как RESTful API, вам необходимо представить ее как набор ресурсов, а все операции над этой информацией выразить через набор предопределенных операций. Фишка в том, что во многих задачах этих предпопределенных операций вполне достаточно, главное правильно определить ресурсы.
Важно понимать, что "ресурс" это обычно некоторая сущность, "существительное". Как правильно заметил Антон Жуков , ресурс /getItems хоть и может существовать в принципе, говорит о неудачно спроектированном API (действие представлено как ресурс).

Есть и другие подходы к архитектуре распределенных приложений, например архитектуры, основанные на RPC (удаленный вызов процедур). Информация в таких архитектурах также представлена в виде некоторого набора сущностей, однако операции над ними определяются конкретной задачей, и для каждой сущности будет свой набор. Это больше соотвествует классическому ООП-подходу. Таким образом, RESTful следует подходу много сущностей (ресурсов) - мало операций (и эти операции известны заранее), а RPC - немного сущностей, но много операций над ними.

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

Сама архитектура REST не привязана к конкретным технологиям и протоколам, но в реалиях современного Веб, построение RESTful API почти всегда подразумевает использование HTTP и каких-либо распространенных форматов представления ресурсов, например JSON, или, менее популярного сегодня, XML.

Смысл использования REST в том, что принципы, хорошо показавшие себя в "человеческом" веб и позволившие построить самую большую распределенную ИС, применяют и для "веба машин".

Ответ длинноват, но как короче объяснить, чтобы не исказить понимание, не представляю. Если что непонятно - спрашивайте.

Вам нужно определить, какая сущность главная, а какая второстепенная для вашей программы. Как это будет выглядеть? Сначала заводится список тренеров а потом к ним крепятся команды? Или, наоборот, есть список команд и нужно создать им тренера? А может, это равнозначные сущности, и вы хотите иметь возможность завести список команд и список тренеров независимо друг от друга, а уже потом проставить связи?
Ставьте внешний ключ той сущности, которая не будет иметь множественной связи с большей вероятностью.
К примеру, если это соц сеть для тренеров, то вероятнее всего, тренер сможет добавлять список команд которых он тренировал. И тогда trainer_id пригодится в teams.
Но если ваша соцсеть вырастет и там будет база команд, которые тренер сможет выбрать из выпадающего списка (т.е. у команд тоже может быть много тренеров), то придется делать M:N. Ваш случай связи 1:1 возник только потому что ваше приложение еще недостаточно развилось.

Также не забудьте что 1 к 1 реализуется назначением UNIQ ограничения на внешний ключ. Иначе это 1 ко многим.

Drovosek01, то как Вы написали веб сервер не годится для реальных задач. Вам легче и лучше было бы переписать сервер используя библиотеку или фреймворк (bottle, falcon, flask, ...). Но если целью стоит изучение работы сокетов, то:

1. Ваш сервер однопоточен и блокируемый. Причина может крыться в этом, т.к. браузер вполне может соединяться с веб сервером параллельно в несколько потоков. Посмотрите примеры неблокируемого режима сокет сервера и/или используйте нити (threads). Если будет сложно, как я и писал переходите на высокоуровневое программирование.
   
2. Причина остановки может быть пассивное закрытие сокета из за TTL к примеру. Проверяйте работы сокетов не на высоком уровне(Chrome), а на низком используя WireShark. Т.к. у Вас не отлаженный низкоуровневый код.
   
3. И по поводу возможного TTL, способ которым Вы создаете страницу, уж простите, ужасный. Хотя бы перепишите возврат шаблонов в таком виде:

   def index():
       with open(os.path.join(dir,'templates/index.html'), encoding='utf-8') as template:
           buffer = template.read()
       while True:
          yield buffer

   Чтение с диска на кажде соединение, даже если у Вас SSD, это как то черезчур там более в таком простом случае
   

В версии 1.11 поддерживают совместимость с IE6-8. В версиях 2.* от поддержки старых IE отказались. По функциям они одинаковые, просто версия 2.* немного легче из-за вырезанного кода.

Потому что %20 это код пробела