Как будто объектно-ориентированные структуры в реляционных базах данных
Я думаю, что проблема в том, что loadMoreCells вызывается слишком много раз.
попробуйте использовать эту проверку вместо willDisplay:
if indexPath.row == yourArrayOfCells.count - 1{
loadMoreCells()
}
ОБНОВЛЕНИЕ
Так что у меня есть некоторые из тех же проблем, после некоторых копаний я нашел это решение для себя:
//conform to UIScrollViewDelegate
let threshold : CGFloat = 10.0 // threshold from bottom of tableView
var isLoadingMore = false //checks if API session ended
func scrollViewDidScroll(_ scrollView: UIScrollView) {
let contentOffset = scrollView.contentOffset.y
let maximumOffset = scrollView.contentSize.height - scrollView.frame.size.height;
if !isLoadingMore && (maximumOffset - contentOffset) <= threshold {
self.isLoadingMore = true
DispatchQueue.main.async {
loadMoreCells()
self.isLoadingMore = false
}
}
}
Если запрос API происходит слишком быстро и загрузка выглядит смешно, вы можете добавить задержку:
DispatchQueue.main.asyncAfter(deadline: .now() + 1) {
loadMoreCells()
self.isLoadingMore = false
}
Если это не сработает, я буду считать, что проблема не в коде, который вы предоставили.
UPDATE-2
Эти 2 функции в setUpCell () не являются необходимыми:
tableView.beginUpdates()
tableView.endUpdates()
10 ответов
Вот решение, которое я предложил приблизительно 10 лет назад. Система, которая использует этот дизайн, все еще работает, таким образом, это работало достаточно хорошо для выживания дольше, чем большая часть моего кода.;) Сегодня я могу использовать один из пакетов ORM, которые упоминает Scott, но нет действительно никаких огромных проблем просто с помощью SQL непосредственно.
Модель все Ваши отношения наследования как соединения между таблицами. Каждая таблица в Вашей системе будет содержать атрибуты определенного класса.
Используйте синтетический идентификатор объекта (oid) в качестве Вашего первичного ключа для всех объектов. Генератор последовательности или столбец автоприращения необходимы для генерации значений oid.
Все наследованные классы должны использовать тот же тип oid в качестве своего родителя. Определите oid как внешний ключ с каскадным, удаляют. Родительская таблица получает автоинкрементный столбец oid, и дети получают простые столбцы oid.
Запросы на заключительных классах сделаны на соответствующей таблице. Можно или присоединиться ко всем таблицам родительского класса в запрос или просто ленивую загрузку атрибуты, в которых Вы нуждаетесь. Если Ваша иерархия наследования глубока, и у Вас есть много классов, пакет ORM может действительно упростить Ваш код. Моя система имела меньше чем 50 классов с максимальной глубиной наследования 3.
Запросы через дочерние классы (т.е. запросы на родительском классе) могут или ленивая загрузка дочерние атрибуты на основе на экземпляр, или можно повторить запрос для каждого дочернего класса, к которому присоединяются с базовыми классами. Ленивые дочерние атрибуты загрузки на основе запроса родительского класса требуют, чтобы Вы знали тип объекта. У Вас уже может быть достаточно информации в родительских классах, но если не необходимо будет добавить информацию о типе. Снова, это - то, где пакет ORM может помочь.
Виртуальные занятия без членских атрибутов могут быть пропущены в структуре таблицы, но Вы не сможете запросить на основе тех классов.
Вот то, что "показывают мне, вся связь только с агентами рабочего типа" похожа.
select * from comm c, worker w where c.actor=w.oid;
Если у Вас есть подклассы коммуникации, и Вы хотите сразу загрузить все атрибуты дочернего класса (возможно, Ваша система не позволяет частичную конструкцию), самое легкое решение к нетерпеливому соединению на всех возможных классах.
select * from comm c, worker w, missive m where c.actor=w.oid and c.oid=m.oid;
select * from comm c, worker w, shoutout s where c.actor=w.oid and c.oid=s.oid;
Одна последняя вещь. Удостоверьтесь, что Вы имеете хорошую базу данных и исправляете индексы. Производительность может быть серьезной проблемой, если Вы база данных не можете оптимизировать эти соединения.
.. Это о, "как я отображаю структуры ООП на таблицы базы данных безболезненным способом".
Вы не делаете.
Объектно-ориентированная и алгебра отношений является двумя существенно различными парадигмами. Вы не можете перейти между ними без субъективной интерпретации. Это называют несоответствием импеданса и назвали Вьетнам Информатики.
Это назвало ORM или Объектное Реляционное Отображение. Существуют десятки продуктов, которые подразумевают помогать Вам отобразить структуры OO на реляционные таблицы. Ruby on Rails, например, предлагает Активную Запись, чтобы помочь соединить деление мостом. Для PHP Вы имеете, Продвигают и Доктрина и Оттоманская Порта и многие другие.
То, что Вы ищете, является Непересекающимися подтипами... ORM является взломом.
Подход, который Вы предлагаете, кажется выровненным по ширине мне. Можно добавить actortype столбец к базовой таблице агента для дифференциации между различными типами агентов. PK каждой определенной таблицы агента был бы FK к actorbase таблице, чтобы избежать, чтобы 'волосатые' запросы и эмулировать подобное наследованию 'были -' отношения.
Это, вероятно, стоит Вашего времени, знакомясь с Объектной Ролью, Моделируя, как обсуждено в этом вопросе. Самая большая проблема, которую я вижу, состоит в том, что нет никакой существующей принятой методологии для того, чтобы иметь концептуальную дискуссию дизайна о реляционных данных. Лучшим, которое можно сделать, является логическое моделирование (ERMs обычно). Объектное Ролевое Моделирование обеспечивает основание для того обсуждения. Я надеюсь, что Вы будете видеть распознаваемые артефакты из подобного обсуждения дизайна ООП, которое Вы могли бы иметь.
Пара людей отметила объектно-реляционное несоответствие импеданса. Лучшее решение состоит в том, чтобы просто воздержаться от RDBMS в пользу OODBMS, который недавно возвратил популярность.
Тем не менее нет никаких объектных баз данных с API в чистом PHP, насколько я знаю. Быстрый поиск привел к этому результату, но он не был обновлен в течение многих лет. С другой стороны, я услышал о большом количестве объектных баз данных для других языков, включая В спящем режиме, db4o, и ZODB.
Много RDBMS предлагают функцию наследования таблицы, которая связывает родительские таблицы с дочерними таблицами почти таким же способом как наследование классов. реализация варьируется немного от поставщика поставщику, но она может вынуть часть боли из реализации подобных понятий.
Кроме того, большинство RDBMSs имеет некоторую комбинацию триггеров, сохраненных представлений и хранимых процедур, которые могут разделить поведение от реализации. Во многих случаях, такие как правила PostgreSQL (обобщение представлений) предлагают очень сложную инкапсуляцию и довольно просты в использовании.
лучший ответ я когда-либо видел это, был: http://en.wikipedia.org/wiki/The_Third_Manifesto
К сожалению, это не что-то, что соответствует в течение единственного ответа здесь на stackoverflow. Я попытаюсь сократить его здесь, но я предупреждаю Вас, что такое сокращение не будет точным отражением третьего манифеста. Перенаправьте все критические замечания этого решения фактического чтения проклятой вещи, вместо того, чтобы предположить понимание этого полностью от чтения сокращения. Хорошо, здесь это идет.
определите три новых типа столбца, названные рабочим, работодателем и контактом. Храните объекты каждого из этих типов в столбцах их соответствующих типов. Следуйте стандартным правилам нормализации для остальной части Вашей модели данных.
Мое чувство состоит в том, что текущая популярная технология базы данных на самом деле не поддерживает "корректный" способ сделать эти вещи, (а именно, много систем баз данных не позволяют определение новых типов). таким образом, не имеет значения, что Вы делаете, Вы будете всегда вынуждаться в ситуацию с компромиссом. Но после чтения третьего манифеста, по крайней мере, Вы будете знать то, на чем Вы идете на компромисс.
ORM в настоящее время является в подавляющем большинстве популярным решением проблемы в данный момент, но я не полагаю, что это - правильное решение.
Мне просто похоже, что Ваша модель данных пропускает уровень. Я установил бы его больше как это:
Люди Таблица - (Просто информация о фактических людях)
Ролевая Таблица - (Типы ролевых людей могут иметь т.е. Рабочий, Работодатель, Контакт - и информация, характерная для той роли),
Таблица PeopleRoles - (people_id, role_id, возможно, запускаются / изменяет даты и т.д.),
Таблица объектов - (Определяют различные типы Объектов),
Таблица RoleEntities - (role_id, entity_id, и т.д.)
Затем изменение Человека от одной Роли до другого (или разрешение им иметь несколько ролей) являются простым обновлением.